The Business-IT Value Chain: An Approach to a Targeted Enterprise Architecture Practice
Shridhar Rangarajan
Director of Enterprise Architecture | Driving Digital Transformation with Generative AI | Expert in Cloud Solutions, Microservices, & Scalable Architectures
Often, enterprise architects are engaged in programs that have at best, nebulous reasons or goals defined for an existing or a newly initiated enterprise architecture (EA) practice. There is very little, or no business context articulated that may serve as a rationale or a guide for the EA practice. For example, the goal may be “deliver enterprise-wide reuse” or “align IT solutions with business strategy and objectives” and so on. Enterprise architecture is complicated and is a strategic discipline to begin with. It would help immensely if there were a clear set of business objectives defined for the enterprise, and for the several business units and departments that constitute the enterprise that the enterprise architect can leverage. This point should make immediate sense since EA is primarily about the business, not IT.
Objectives-Key Results-Initiatives (OKRs), against this background, become the necessary driver and input for a targeted outcome-centric enterprise architecture practice. The goals of enterprise reuse, digital transformation, business-IT alignment, etc. can be viewed and assessed in the context of the enterprise’ larger set of strategic objectives, and the key metrics that need to be met within a certain time-window. The OKRs can thereby provide the foundation for a set of high-level use cases that the EA practice can begin defining and prioritizing.
That said, the next question for the enterprise architect is where does the EA practice begin once the OKRs are visible to the EA practice. To this end, a map of the Business-IT Value Chain and the aspects that inform / influence / impact each of the stages in the value chain will serve as a practical starting point to determine the short- to mid- to long-term scope of the EA practice. The map will help in scaling out the program (and the business-IT value chain) iteratively and incrementally as the EA practice begins delivering value in short agile sprints. This value – described as MVPs (Minimum Viable Products) released in successive versions across frequent intervals – should be targeted at realizing the stated objectives in the OKRs while meeting the key results. The MVPs must also align with and support the initiatives underway to produce the key results.
It should be evident that the stages in the business-IT value chain are just individual links in the chain, and the chain is only as strong as its weakest link. At the leftmost end of the chain, the Business is a customer of the EA practice. The business describes the business vision, strategy, and the business roadmaps to which the OKRs are anchored and guide the IT initiatives. The business context is identified, developed, and used by enterprise architecture to map the context to business requirements, and other architecture elements such as solutions, applications, and enterprise services. The business requirements flow into the IT realm where IT situates the requirements in solution roadmaps that describe the baselined current state, a set of transition states, and the target state. The implementations of the various states then manifest themselves as “things of value” to the end customers of the enterprise, who are at the rightmost end of the business-IT value chain. The EA practice therefore has TWO principal customers that it must work with, deliver results to, and ensure their success. Additionally, one can never over-emphasize the fact that business architecture is truly the key and the glue between the OKRs and the rest of the business-IT value chain.
The annotations in the cells of the map are not meant to be exhaustive. They are instead a sampling of the useful EA and other types of artifacts, sources for standards, reference models, processes, principles, best practices, and the types of tools that can aid the EA practice to ensure that each link in the value chain is enabled and is as effective as necessary to seamlessly integrate and partner with the link before and after in the chain.
It should be noted that industry standards and reference models are meant to be extensible by the enterprise and may be adopted / adapted for an organization’s specific needs. Architecture frameworks such as TOGAF, TMF ODA, etc. may be adopted in bite-sized manageable increments as dictated by the EA program management function based on business / customer value prioritization, resource allocation, cost, and other such influencing organizational parameters. Also at the same time, it is highly advisable to retain the terms & terminology used in the standards and reference models to avoid confusion and needless hours of (stressful) debate down the road.
Hopefully, fellow enterprise and other architects will find the business-IT value chain map useful and convenient to apply in their respective engagements. Please feel free to post your comments, suggestions, and share with others who may benefit in your network.
Lastly, a couple of earlier articles that I posted in this same forum, Connecting the Dots: Strategy to Architecture to Execution and Agile Enterprise Architecture, will make good companion readings for this one.
References:
领英推荐
Business Architecture Guild – BizBoK Guide
DAMA International – DMBoK – Data Management Book of Knowledge
Design Thinking – The set of?cognitive, strategic, and practical procedures used by designers in the process of?product design
EABOK – Enterprise Architecture Book of Knowledge (Mitre Partnership Network)
FEAF – Federal Enterprise Architecture Framework
OKRs – Objectives-Key Results (and Initiatives)
OMG MDA – The Object Management Group’s Model Driven Architecture
SAFe – Scaled Agile Framework
TMF ODA – TMForum’s Open Digital Architecture
TOGAF ADM – The Open Group Architecture Framework – Architecture Development Method
TOGAF Archimate – EA Modeling Language
UML – Unified Modeling Language
W3C – World Wide Web Consortium
President and Founder of Context Consulting
2 年How do you envision maintaining EA continuity when the Objectives change? The underlying assumption in most of these strategy- and vision-driven approaches is that the strategy and vision are stable enough to remain as the implementations proceed - but in so many companies I have worked with, market forces, management shake-ups, or implementation failures drive changes to the strategy and the vision. How can EA avoid having to go back to square 1?