top of page

Enterprise Architecture: a tool for the controlled adoption of a cloud model

  • Jan 30
  • 4 min read

Today, the cloud and the implementation of DevOps practices are at the forefront of key technologies for digital transformation.


But how can an enterprise architecture approach be adapted to the current challenge of controlled adoption of the cloud model? How can enterprise architecture assets be enriched and used to better respond to the challenges of digital transformation?


We have identified the new challenges of an agile and collaborative Enterprise Architecture practice to drive dual alignment with the changing and unpredictable developments in business models and operations on the one hand, and technological innovations or best practices on the other, brought about by digital transformation.


At the forefront of key technologies for digital transformation today are the cloud and the implementation of DevOps practices, with the objectives of selecting off-the-shelf services that functionally meet needs, ensuring the fluidity and speed of delivery of various services (IaaS, PaaS, SaaS), rapid and automated deployment of applications on these building blocks, and the ability to adapt the sizing and, more generally, the expected level of service “on demand.”


This technological evolution and change in practices is now based in particular on the provision and deployment of infrastructure building blocks in the form of managed services offered by the main providers in the cloud market, such as Google, Amazon (AWS), Azure, and IBM.


When it first emerged, this type of solution generated considerable interest and high expectations in terms of resource optimization, sizing, cost, and timing tailored to demand. This view, which was undoubtedly ideal at the time these new solutions were discovered, is now being confronted with the reality on the ground and initial feedback from users. A purely reactive approach is proving insufficient at the IS management level, and it is now necessary to frame it and be able to anticipate a longer-term assessment of sizing and therefore the associated cost.


By projecting the cloud into a product maturity model, whether inspired by Gartner's “Hype Cycle” or J. Appelo's business model lifecycle, a strategic challenge for the cloud today is to accelerate its adoption and transition to maturity.



This avoids a phase of “disillusionment” and allows companies to reach the productivity plateau more quickly. In other words, it allows them to move quickly from a stage that is still strategic (“training”) to phases that are fully operational, financially viable, and profitable (‘crystallization’ and “expansion”).


This is where an agile Enterprise Architecture model, driven by Cloud issues, as outlined above, takes on its full meaning and value.


In recent publications, we have already discussed the ability of an Enterprise Architecture model to represent strategic and business, application and technology, project and implementation views, as well as to highlight the impacts related to the characterization of these elements, a scenario, or a roadmap. This is typically what can be achieved with a cloud solution in order to anticipate its sizing on the one hand and its cost in the medium or long term on the other.


To illustrate our point, we draw inspiration from an ongoing project we are conducting with a client that provides services in the transportation sector, aimed at deploying a “data hub” whose purpose is to provide all the business information required by an ecosystem of customers and partners, and to unify the various data sources managed within multiple business applications. The ingestion and transformation of various information from sources to the data hub, synchronization and integration between applications, consultation via API from a portal, and business supervision of all interactions are carried out via an IBM Cloud integration platform, consisting of an API gateway, an integration bus, and operational and analytical data repositories.


The first artifact produced was the sizing aid. In our context, all the services that feed the data repositories and ensure integration between applications are deployed on an integration bus, initially planned for the cloud. As the initial developments and deployments showed significant resource footprints, a projection of all components on the platform within an Enterprise Architecture model made it possible to simulate saturation situations with respect to the initial sizing.


Modeling integration services and their projection onto infrastructure building blocks makes it easy to visualize whether or not a level of criticality has been reached based on the number of components deployed and their footprint.



The second artifact is cost control assistance. At this stage, and based on the initial simulation, we enrich the Enterprise Architecture model with annual license cost data according to two deployment options for the integration bus, the first in the cloud and the second on-premises, to obtain a medium-term projection. While cost over this time horizon remains the key criterion for decision-making, other criteria are also evaluated, such as deployment complexity and strategic impact.


The model of license costs and their relationship to the two integration bus options allows for a comparison of annual costs and their evolution over time according to the option chosen, thus providing support for decision-making and anticipation.


The Enterprise Architecture model also facilitates the extraction of key indicators and their visualization in dashboards.



These few examples, deliberately simplified and based on fictitious and insignificant data, have enabled us to illustrate an Enterprise Architecture approach adapted to the current issue of controlled adoption of the Cloud model.


Through the two types of artifacts proposed here, we also wanted to demonstrate, using simple examples, how an enterprise architecture asset base can be enriched and used to better respond to the challenges of digital transformation.

Comments


© Gabriel Greenfield

© Gabriel Greenfield

© Gabriel Greenfield

© Gabriel Greenfield

© Gabriel Greenfield

bottom of page