Create Business Agility (Part 2 of 3)
Everyday we see examples of business disruption. What is behind this disruption is software (software is eating the world) and companies that can leverage this will create business agility and gain a real competitive advantage. Many companies, however, have difficulty transitioning to agility because they have legacy lock-in with which to contend. My three part blog series discusses six principles to create business agility. To set context, please read my previous blog — The Knee of the Curve. In part one (my recent LinkedIn post) we covered #1 — Strategy, not only Technology and #2 — Design Thinking.
Warning, this part two is the most technical of the three part series.
Third: Data as a Service (DaaS); data modeling to reach scale
SaaS has provided us with amazing capabilities, better economics than on-prem, and has enabled software to reach more people than thought possible. However, one of the downsides of SaaS is that businesses can lose control of their data. In the SaaS world, where we buy best in class cloud apps, the data in these applications are no longer owned by the IT organization. These applications work well for departments, but are limited in terms Master Data Management (MDM), which can be a problem when talking about scale. This is why we often see sales fighting with marketing, or marketing fighting with finance. The underbelly of SaaS is that we have lost control over MDM, the notion of a System of Record (SoR), and the comfort of transactional data integrity. Designing an agile business model requires one to take back control of data, while allowing the business functions to build or buy the apps they need to run the business and compete. To do this, one must decouple data from applications. Hence, Data as a Service (DaaS), data ontology, then micro-services. Enterprise DaaS and ontology delivers data integration and integrity and scale, while micro-services ensures agility and flexibility.
Enterprise data ontology is critical in creating business agility. Data ontologies allow for connection of heterogeneous systems, resolving any ambiguities that may result when connected. Ontologies can be modeled and created in a variety of manners, either as a single ontology, multiple ontologies, or hybrid. A single ontology is the simplest form, and although that can limit flexibility, is often the most efficient from an effort versus flexibility perspective. Multiple ontologies allow the modeling of individual data sources but requires mapping to enable correlation across domains. Although creating an ontology that provides ultimate flexibility has advantages, the costs can be prohibitive.
In selecting an ontology, consider the operational and strategic requirements of the enterprise and how data is used to participate in fulfilling those requirements. In undertaking this analysis, and taking into account how requirements may have data intersection points, a pattern often emerges where the same data sets are reused between systems. At any point where reuse is identified, a DaaS opportunity should be considered. Once the services have been defined, they can be used as a guide to determine the ontology type and definition. By adopting this approach, businesses create a DaaS, supported by an ontology driven by business requirements and not by the underpinning systems which house the data.
The formation of an internal or external DaaS strategy typically evolves over time. It is usually a result of the implementation of new solutions and integration of legacy systems. Although it is theoretically better to define an ontology that meets the entire enterprise objectives ahead of its inception, it is a process that can be undertaken on an iterative basis allowing the enterprise to grow into expanding agility.
Fourth: From Mono to Micro; how people win
Anyone who knows excel knows they never use all its functionality. Excel is ubiquitous because it is so easy to use and it can do many things for so many different people. However, no person uses all the functionality, not even close. Most people, in fact, use between only 5% and 10%. The reason we do not care is that we do not pay for all of it. If Microsoft had priced it that way it would have never reached ubiquity. Monolithic SaaS or on-prem applications are a little like excel in that there is a great deal of functionality that resides in those systems and most users only use a fraction of the functionality provided. However, these applications are pricey, unlike excel. The other truth is that that these apps are rigid and do not lend themselves to business agility. One must A) purchase the whole in order to use a part, and B) modify user workflow to use the solution. Both of these are serious limitations and the advent of microservices architectures results in increases in agility and reductions of cost.
Once one de-couples data from applications, one can employ an agile / RAD approach to development, using microservices. This then provides the means necessary to create application agility for the business. Microservices complement the DaaS process and allow the enterprise to move from rigid legacy solutions to resilient, flexible services. They typically function independently from one another as discreet processes, and through their combination, allow the rapid creation of tailored solutions to meet exacting business needs.
Using microservices allows the enterprise to create a library of reusable capability. It is important to be able to distinguish between what is common across the business and what is specific to an operational need. The more common the functionality, the greater the reuse. This reduces the number of microservices required and managed. The most important step in creating the microservice library is in the analysis of the business requirements in light of the overall business strategy. Putting time into the analysis will reduce the burden of maintenance and increase the return on investment made in delivering the agile enterprise.
What is commonly overlooked in defining a microservices library is an understanding of those services that currently exist in the public market. Vendors such as Google, SAP, Microsoft, Oracle, IBM, Amazon, etal., provide a variety of useful services that can be easily leveraged in the creation solutions. These services are typically specific in nature but often provide access to systems that an enterprise may already be using.
Just as in the creation of an ontology and DaaS capability described previously, the creation of a library of micro-services can be undertaken in an iterative manner. Where an enterprise consists of numerous systems and processes, it can take some time to form a comprehensive set of services to meet its complete needs. To achieve maximum benefit from the creation of an ontology, formation of a DaaS and the creation of micro-services, a method of combining those micro-services is the final step in delivery of the agile enterprise. There are numerous tools available to developers that enable the rapid development of applications, however, the majority of them are targeted to Software Engineers and do not cater to the Solutions Architect.
If you are still reading, then you got through it. Congrats! This was the think stuff, the stuff that for many of you might not mean too much. However, these are two of the technical underpinnings that must be done to create the agility you are looking for. These are also the two that many people miss. Next week is where we we will rap it up and tie it all together with #5 — The Time Imperative and #6 — How to Organize for Agility.
