Close
We enable business and digital transformation decisions through the delivery of cutting-edge ICT solutions and products...
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. – Software engineering
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 really 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.
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 limit 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.
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.
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.
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.
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 technology trends. No developer likes documentation, but a record of past decisions can guide development teams in the right direction. Contact Musato Technologies to learn about our ICT services.
Gideon Ebonde M. is the CEO and Chief Software Architect at Musato Technologies. He is experienced Software developer with a demonstrated history of working in the information technology and services industry. He has a strong engineering professional skilled in Mobile Application Development, Enterprise Software, AI, Robotics, IoT, Servers, Cloud and business application. He is an accomplished DevOps software engineer and a visionary computer scientist and engineer.
Leave a Reply
You must be logged in to post a comment.