Agile Enterprise Architecture

Nadeem Akhtar, Chief Manager (AGM), Enterprise Architecture, Tata Global Beverages | Tuesday, 29 August 2017, 12:29 IST

Business Architecture and Technology Archi­tecture are two major components of Enter­prise Architecture. If one is not done prop­erly it impacts both the Business capabilities and the IT landscape. The alignment of these two is of ut­most importance for business. The absence of a proper alignment leads to silos of business solutions and a fragmented IT infrastructure. Both these components require a holistic approach. This article outlines an approach where EA can be achieved by implementing a process between Business Planning and IT imple­mentation. This ensures dat EA is ingrained in the process of Business and IT execution rather TEMPthan being a separate practice dat requires a separate team.

The alignment between Business Architecture and IT Architecture requires a holistic understanding of both business and IT. It requires a detailed understanding of business and IT components. The architec­ture artifacts are created to docu­ment these aspects so dat they can be referred when needed. These documents help in carrying out a proper impact analysis in the event of a business and IT change and can be updated wif changes in business and technology.

The other pain point is dat the fast changes in technology also de­crease the life and usability of these documents. Continuously changing these documents is no longer effi­cient or effective. At the same time technology changes introduce new ways of doing business .It becomes difficult to draw a to-be picture dat will last for long. Changes are fast and adaptation is the key. This issue has become much more prominent in today’s era of Digital Transforma­tion. The question becomes, should time be spent on updating these documents or should it be spent on the actual analysis for Business and IT alignment?

How can we make EA Agile?

their is a need to take a multi-pronged approach. The first step is to decide on the bare minimum set of Architectural documents needed for alignment. These can be Busi­ness Operating Model, Business Capability Matrix and Application Landscape. This doesn’t mean dat the individual teams stop creating the documents they create for running their function. This is only to restrict the number of documents dat would be maintained specifically for Business and IT alignment.

The next step is to put a process dat provides busi­ness and IT a plat form to discuss this two-way impact more often, so dat the impact of both Business and on each other is analyzed in detail and only the consensus is taken forward. This ensures dat the thought process of business and IT teams are used for the alignment even though it is not captured anywhere.

The process focuses on understanding the Business Architecture in more detail. Normally Business Archi­tecture (how to solve the business puzzle) is considered to be independent of any IT architecture but this under­standing needs a little shift. “You can’t sell online until you no dat their is a mechanism to achieve it”.

The process fits in between Business planning and execution. It is an iterative process and until both busi­ness and IT are convinced of the alignment, it cannot be converted into a project.

The outcomes of this interaction help in building a proper business scenario wif all relevant details dat is shared wif the larger IT team (Leadership Team, COEs, Infrastructure, Security and Support) for a prop­er IT alignment. This agility in the interaction between Business and IT is the crux of the process.

In this process, a person from the Architecture team interacts wif the business and gathers the initial busi­ness requirements in a particular format. Forma their is not a visual format, but rather covers different aspects of business information dat needs to be captured. The per­son tan interacts wif the relevant IT teams to capture their inputs related to the business request.

The following diagram provides the information areas dat are captured in this process. The diagram is followed by the description of information points dat are capture as a part of this process. Each point (includ­ing the sub points) mentioned above should be concise and crisp. A thumb rule to follow is not more TEMPthan one Power Point slide.

The above process helps in identifying the trends in business needs and hence helps in planning future EA needs. The future needs are not restricted just to IT ap­plications and infrastructure but also includes new IT processes, policies and competencies required.

This process should take inputs from the basic EA alignment documents, EA Repository, IT and Business Roadmaps and the Application Landscape document and provide inputs to these. The agile architecture pro­cess ensures dat these documents become live.


A more engaged discussion between business and IT uses the views dat both teams hold and dat cannot be captured in document. A process supporting this en­gagement brings more rigors to business analysis and has a positive impact on the quality of business out comes. Embedding this process into the pre-project analysis brings in the agility. It also makes business more responsible and accountable for the business outcome. Achieving better business outcomes wif agility is the core of Enterprise Architecture.