Many EA programs are actually IT management ones, especially if there is not a Business Architect on the EA team. Even if there is a Business Analyst, too often, there are no senior business representatives in the EA governance and operational roles. In many cases where there is the “equivalent” of a Business Architect helping out the EA team, it is only in a matrixed manner because business domain experts usually exist in the business chain of command.
There is also confusion between the Business Analyst and Business Architect roles. The role of the Business Analyst is normally focused on gathering project requirements and helping with administrative tasks tied to procurement. Of course, a Business Architect has a wider range of responsibilities and competences, including documenting business capabilities, actors, roles, information, processes, functions and services.
Often Business Process Modelers are seen as being Business Architects. However, out of the list of important elements needing documentation, listed above, they are mainly focused on business processes. In such a setup, critical aspects of change related to Business Architecture can be easily overlooked or covered in an ad hoc way.
The use of an architecture metamodel that includes the business domain as well as the IT/Technology ones can greatly facilitate more comprehensive and consistent coverage of business aspects of any transformation initiative. For example, with a common metamodel, a Business Architect can more coherently create viable As Is and Target architecture documentation. However, most leading EA frameworks and associated metamodels are missing financial elements in their business domain. As a result, even with a core Business Architect function on the EA team, the team is not fully equipped to talk to the business in terms of financial considerations. Neither the TOGAF, FEAF, DODAF and ArchiMate metamodels have financial elements.
The Federal Aviation Administration has adapted DODAF to include a financial viewpoint. The TRAK framework includes executive and procurement viewpoints – in fact, it was developed because of large overruns on a major engineering project.
According to Gartner, “Organizations without a plan for cloud cost management may be overspending by 70% or more.” Similarly, according to McKinsey, “Architects need to move away from PowerPoints that emphasize structure and systems to focus instead on understanding the language of business: scenarios, P&L impact, ROI, risk, trade-offs, and so on.” At a recent conference hosted by Avolution, one presentation suggested that EAs need to become better communicators, including for analyzing financial dimensions of change. For example, an EA work product in the near future could include:
Dashboards to Inform & Motivate
> Explain how a project will increase sales, market share, competitive advantage
> Use this business goal in your dashboard and report “headlines”
> A roadmap is not complete until it is communicated: costs, resources, impacts
In Gartner’s Tech and Innovation Summit for 2022, some of the following points were highlighted that could certainly relate to Business Architecture
Business Outcomes = Value
Return on investment (ROI)
The value in dollars that will be gained or saved by implementation and usage (business outcomes)
Total cost of ownership (TCO)
Net present value (NPV) of the purchase over a period of time
Types of information that were found the most valuable in making the final decision
Value assessment or business case development-related content
Modern content: Videos, audio, infographics, podcasts
Content that was specifically tailored for us
I have modified a statement and recommendations from the same Gartner event mentioned above for the following observations from an EA perspective:
Higher preference will be given to EA consulting practices that can provide business value calculation during the pre-engagement process and value realization post-engagement
Inventory your EA team’s ability —across domains—to articulate its value to stakeholders and its ability to assess value for them.
Create value hypotheses, models, metrics and assessments based on your target use cases and related audiences.
Align value-oriented content and practices with customer journeys mapping.
Create disciplines and capabilities for both value assessment and value realization to attract, retain and grow satisfied stakeholders for your EA practice.
Conclusion
EA programs of the future need to embrace and enhance the role of Business Architects in terms of their expected contributions to business cases, narratives for value realization, and, overall, for aligning some Business Architecture work products to the financial concerns of the stakeholders the EA team is serving. There are huge opportunities to nurture this discipline, given the low attraction for Business Architect jobs at present.
EA Principals consults on ways to expand metamodels and develop business cases to help EA teams explain their value and the value of their recommended building blocks for moving from a baseline to a target architecture. Contact us if you would like to learn more about this service at [email protected].