michelangelus - Fotolia
How component-based software engineering spurs innovation
Demands for digital transformation in business may ring hollow to some architects. However, componentization can play a key role in making business innovation a reality.
Architects and developers have too many priorities and too many high-level goals as it is. The introduction of broad business imperatives, such as application modernization and digital transformation, do little to create a technical approach or define a software architecture. The best way to realistically approach these demands is to get your terms straight, frame applications along modern cloud component lines, introduce component-based software engineering to make processes match business needs and recognize productivity and technology trends as equals.
The strategy
A primary technical step in creating a business transformation bridge is to focus on component-based software engineering, part of which involves having a componentization strategy. Componentization is driven by two forces: functional requirements from the business transformation side and technical requirements from the application modernization side.
The functional side of componentization is created by the tasks workers perform and the application tools they use. The goal of functional componentization is to create components at the highest level and avoid a specialization of functions that limits sharing components among applications. Always start your plans around component-based software engineering at the functional level. If you have an enterprise architecture (EA) organization, functional componentization should be a joint activity between enterprise architects and application architects.
Technical-level componentization can break down functional components to make them more scalable and resilient. Look for functional components that have a mix of either process-intensive and process-limited activities or stateful and stateless elements to identify your primary targets. Remember that componentization imposes a price: an accumulated delay in connecting workflows. Take it only as far as benefits in availability and scalability justify the move.
Aligning business needs with technology adoption
Once you've identified the functional goals and broken applications into functional components, the next step is to accommodate new technical developments. Three major technology areas to focus on are the worker interface (i.e., mobile devices), the use of information (i.e., big data and analytics) and the hosting of application components (i.e., virtualization and the cloud). It's critical to stay within the functional boundaries set by business process requirements. But when alternative approaches with the same functional benefits can be identified, pick the approach that aligns best with longer-term technical trends.
A few needed definitions
In order to meet demands for innovation in business, architects and developers should understand what exactly the broad terms associated with today's business innovation mean. Here are three terms everyone in IT should try to understand:
- Application modernization: A process development teams are familiar with, because, in most cases, the term is applied to making changes to applications to take advantage of modern technology concepts.
- Business transformation: A change in the way a company conducts business, which means focusing on functionality rather than on technology. Because business transformation creates new worker missions, it also creates new functional requirements for applications and, in some cases, a need for new applications.
- Digital transformation: The link between business transformation and application modernization. It creates a multiapplication vision of modernization to accommodate new technologies and also forges a path to redefine business processes and transform operations overall.
Technology-driven application modernization projects often need to focus on one or more technology trends, such as mobility. Unified transformation and modernization projects must presume that business practices will ultimately drive adoption of the three key technology areas cited above. That requires picking a technical approach in all three areas. If there is concern about the integration of all these options, use a vendor that has the full spectrum of platforms and tools. It's also imperative to plan for public cloud hosting from the start, which may affect the componentization strategy since many businesses can't host critical data in the public cloud and depend on a link back to the data center for access and updates.
Introducing composability
Making applications composable to facilitate accommodating changes to business processes without new development should almost always be a goal of any digital transformation process. Identifying common tasks to guide functional componentization can be difficult, particularly for companies who haven't used EA to identify business processes at a detailed level. If your unification goals include a strong business transformation focus, you won't have the benefit of past experience to guide you, making a careful review of business processes very important. There is a temptation here to simply take business function descriptions and translate them into software, but this will almost always result in too much unique, siloed development. It's best to have a series of meetings between EA and business process specialists from the line-of-business group on one side and then between software architects on the other. This can help package multiple business processes into a smaller set of implementations, facilitating component reuse.
Development teams can often catch componentization practices that limit composability, because both architects and developers will find themselves describing the same thing multiple times. When this happens, don't automatically assume you need more components. Rather, check with line-of-business specialists to ensure that practices and needs aren't diverging. Also, be wary of overdoing componentization and increasing processing delays and fragility of applications.
The modern trend to adopt microservices can enhance application resilience and scalability, as well as improve composability and responsiveness to changes in requirements, but it is also very easy to overdo. With microservices, as with any other mechanism of component-based software engineering, it's important to watch for situations where two or more components are always used together. Unless the scalability and resilience requirements for these chains are very different, consider combining them to make your development more efficient.
Tying it all together
The final step in unifying application modernization, business transformation and the digital transformation process is keeping the process unified. This isn't going to happen unless organizations document steps. This involves not just describing what's been done, but why it was done. The assumptions you've made, combined with new drivers in business processes, business goals and technology elements, will determine how you adapt your applications to meet future business requirements and take full advantage of emerging technical trends. No developer likes documentation, but a record of past decisions can guide development teams in the right direction.
