12 Establishing and Evolving the EA Capability
By defining the process to implement the EA Capability framework, governance framework, and a roadmap to implement and manage EA initiatives, there should be a blueprint to assure the outcome expected from the team providing the EA Capability. By defining the organization model for the EA Capability team and building the structure to capture and manage architectural contents, the team’s ability to execute on the specified course of action (roadmap) is assured as well. Each of the chapters until now presented discrete topics of concern. This chapter is focused on providing the linkages across these topics to enable a “Sustainable EA” practice. It is better to use proven methods like a capability or value chain model to stitch the pieces together and formulate a management approach.
An EA Capability team is a collection of people (architects, analysts) who employ a set of common processes to manage the set of information about the organization to enable achievement of the enterprise’s stated purpose. The EA Capability is the ability to develop, use, and sustain EA.
The enterprise’s leadership are the EA Capability’s customers. The Leader should articulate purpose, ethos, and delivery to its customers. Focus on the outcome the EA Capability will deliver; foundations for future scale and function clarity; and the flexibility to adapt and change with the enterprise’s environment. Follow the same concepts of identifying the gaps, defining the constraints and controls, and incorporate the flexibility needed to periodically adapt the EA Capability when developing a roadmap.
This chapter deals with the concept of capability in the context of a management model that allows for innovative applications and redeployment across the enterprise.
12.1 Recap of Concepts
Up to this point in the Guide, generic leadership and management concepts relative to the EA Capability, including the incarnations it could have had in the past, were presented. Some of the key takeaways from that discussion are:
- Purpose of the EA Capability
- Development of, using, and managing architecture
- The relationship of EA with other disciplines within the enterprise
- It is necessary to refer to this Guide and the TOGAF ADM more than once to deliver value
Afterwards, the Guide discussed the importance of the organizational context and the need for an EA practice. During this conversation, differences between the organizational outcomes and team structure were discussed. While discussing process model, the Guide presented different organizational cycles and budgeting ceremonies. Likewise, governance, risk, reporting, and financial model presented views for implementation controls. We also discussed that the team providing the EA Capability should assess why the architecture work has been initiated, readiness, and maturity in absorbing architectural information. This understanding drives the definition of the content model, viewpoints and views, and use of a repository.
Having gained knowledge about the organization and its intent to engage in economic activity (values and business motivations), the Guide discussed the objectives and need for setting up an EA Capability. One of the key principles to focus on is the value delivered to and iterated by the TOGAF ADM to the extent required to deliver value. It is imperative to scope the depth and breadth of the EA work commensurate with time and objectives. Later in this chapter, there is a discussion called Sustaining and Maturing (in Section 12.5) relating to leveraging the span of control the EA Leader currently has, expanding it, and thereby iterating the ADM cycle to keep adding value.
It may be a reality that there are people in the enterprise who perform architecture development without carrying appropriate titles or following a particular career path. Similar to following the money trail to create a forensic map of cash flow and value addition, following the artifacts will lead to where the architecture work gets done and who performs it. Creating a map of the diverse role titles to appropriate architecture domain roles will create a view of the architecture community. This is the community or extended team that the EA Leader should nurture and utilize to deliver EA Capability. To deliver on the charter, it is required to build the capability and capacity of the EA team, commensurate with the demand.
Then the Guide discussed selection, customization, and use of EA and related delivery assurance frameworks. It is important to identify and define the interaction points between product and service delivery strategy to the TOGAF ADM (or the customized architecture method). This can also be evolved as the breadth and depth of the mandate for EA work evolves. The following chapter discussed the need to have a governance model that balances how the team providing the EA Capability goes about development of architecture artifacts and how it engages with rest of the enterprise.
Finally, for the data that EA manages, the significance and need of structure, the Content Framework and Content Metamodel, and an automation tool were discussed.
12.2 Start with Purpose
In a world of multi-point competition, ease of availability of substitutes, and continuous pressure of quarterly fiscal results, organizations are forced to create waves of revenue models via new products and services, contractual commitments, or expansion of customer base.
Based on the alignment of the EA Capability team, the purpose for EA could be cost control, risk optimization, strategy development, or variants of these factors. Even if the charter evolves, expectation to deliver on the primary intent and focus generally does not go away. This assessment and grounding is based on the purpose for which the enterprise is engaged in the economic activity as well as why the team providing the EA Capability is formed.
Just like how the enterprise approaches identifying new models to generate revenue, suppliers of products and services to the enterprise also come up with different methods, models, or versions of their products to force changes to the ecosystem. Based on the assessment of the enterprise, the EA team will have to identify and project out when the enterprise will have to start engagement with these emergent technologies and concepts. The EA Capability team acts as subject matter experts in providing a review of the emergent concepts, technologies, and patterns to the stakeholders and decisions-makers. Such review documents should align with the purpose for which the EA Capability effort was created.
One of the key advantages an Enterprise Architect has is the ability to look at the system under discussion without any bias to the views of the executives and implementers, customers or support personnel, and security or compliance officers or developers, technology or time. When an Enterprise Architect presents a balanced view, supported with rationale addressing future needs, trade-off conditions applied, accounting for culture of the company, teams generally gravitate towards common goals setting aside emotional favorites. Stakeholders invariably want this insight from the Enterprise Architects to validate that they are on the right path or to fail fast and course correct with the least sunk cost. The expectation is also that the Enterprise Architect provides an honest impact assessment and risk mitigation alternatives. Experience has shown that raising what could normally be perceived as the most uncomfortable set of questions instigates a chain of positive changes in the enterprise.
The EA team should create a periodic assessment of readiness the enterprise has for adopting EA practices or new technologies – the next leap of value delivery. This assessment helps the team providing the EA Capability to time the case for expansion of the charter. Ambitions for growth in charter as well as maturity aside, the goal is to ensure that the team providing the EA Capability stays relevant and current with the ecosystem and business needs.
12.3 Trusted Advisor and Instigator of Change
Most organizations today are not starting blue ocean strategies;[26] several of their initiatives are the n+1th attempt to solve a business problem. In such scenarios, when solution alternative evaluation or solution development efforts begin, modern lean methodologies do not lend themselves to view the broader context of the enterprise. An Enterprise Architect understands inter-dependencies within and outside the enterprise and can guide the teams to create appropriate points of isolation. An EA team should communicate clearly and continuously the shared vision for the enterprise and how all stakeholder groups are coming together behind that vision. Moving the focus of the vision from the typical inside-out view to an outside-in view elevates the thinking of key decision-makers. Instilling the thinking for points of isolation to manage change and to manage rapid response to market dynamics brings trust in the people and, hence, to the team providing the EA Capability.
EA Capability teams that focus and deliver key organizational transformations are statistically more successful than teams that focus on standards, reference architectures, processes, and governance structures. Such a demand at times has caused scale issues for the team providing the EA Capability. To scale, successful EA teams have employed techniques like franchising typical work such as impact assessment questions and trade-off considerations. To employ such techniques, the process should be well defined.
When engagement opportunities to land organizational changes or to franchise are not directly available, the development and publication of point of view documents has proven to be a successful technique to influence change. Monitoring and assessing which points of view get read and by whom presents the stakeholder interest. Tracking the changes those stakeholders initiate results in peer-level acceptance. Communicate and share the credits of initiatives to establish the team as agents of change.
12.4 Change Management
As business dynamics change, organizations undergo change – informed by the team providing the EA Capability or otherwise. It is necessary for the EA Capability team to track changes in the external ecosystem and create point of view documents. To sustain and grow the EA Capability, the Leader should prepare a list of recommendations for the decision-makers about transformation(s) needed to keep the enterprise abreast or ahead of ecosystem changes. Some transformations may require a change in operating model and some just an alteration in product mix. The range of coverage in point of view documents may include changes in operating model, technology adoption, risk reduction, or the nature of services offered or trade-off criteria to mitigate. Depending on the charter, the EA Leader should indicate to the decision-maker when a hype would become a necessity or cost of adoption and risk of failure is balanced appropriately.
The trend since the new millennium is increased complexity of products and services that uniquely differentiate from potential current and future competitors. Some of these products and services reduce dependency on certain skill sets and some require new and specialized skills. Also, several products and services are being developed using deep collaboration with niche partners. The cost of collaboration has been falling, and diversity of service providers has been growing. Organizations have been shrinking the core and expanding at the edges. In such an era, success factors and competence drives the strategy based on how well the sets of activities performed by the enterprise dovetail with one another. When EA creates an enterprise map – that has the depth of capabilities, processes, technologies, training, investment flows – operational fit across teams and themes of strategy realization come to light. Once again, just like the advice provided to business, periodic development of the case for change of the EA Capability informs the team to update its skills and to stay ahead of rest of the enterprise.
In general, enterprise plans do not question the assumptions made for an effort nor do they justify clearly why something has to be done and when. Most of the business cases are based on the affordability of the enterprise to spend its resources. EA roadmaps present the reason for something to be done and present the alternatives – each with implications – tracing assumptions to predictive outcomes. In this approach, ease of change, validating change as time passes, and an assessment of “what the end looks like” can be painted clearly to guide organizational, product, or process change.
12.5 Sustaining and Maturing
To sustain and mature the EA Capability, the Leader should assess the capacity to execute and validate the possibility of change in charter or scope with the sponsors:
- A function-centric EA – focus would be on appropriate business and process architecture, technology sourcing, and cost of operations.
- A strategy-centric EA Capability – enablement of sustainable strategic advantage, leveraging technology as a business accelerator, balancing inside-out and outside-in perspectives. Irrespective of the nature of alignment, there is a need to have the members of a team with varied styles of thinking and execution (star gazers, anthropologists, and planners).
- An IT-centric team – the challenges are going to be pivoted on CIO priorities: reducing cost of operations and agility to meet the business needs, keeping the ecosystem current with technological updates, and so on.
The styles of these people complement the enterprise capabilities at strategic (executive engagement), value addition (managing composition of the enterprise), and coordination (common services) levels. As one of the former CEOs of Shell Oil puts it: “people are the difference”. EA – as much as it is about business strategy and technology – is people-centric. To grow the capability, the Leader’s motivations should be grounded on people engagement. It is the responsibility of the Leader to nurture these three styles and find a balance for the people possessing them to be executing on a common set of principles and beliefs, namely: connectedness, inclusivity, and relevance.
Figure 24: Sustainable EA
12.5.1 How to Engage and Promote Value Execution of the Internal Stakeholders
A team providing the EA Capability with adequate sponsorship has no cost or overhead to acquire new engagements. The challenge is that the buyer base of EA Capability is predefined – unless the enterprise decides to broaden its footprint. In this case, the focus should be about retention and repeat business from the same set of customers. Several techniques can be employed from the public relations and project management playbook to achieve this. Measure quantitatively and qualitatively to communicate every small improvement and value addition the EA Capability team has delivered in terms that are close to the primary and secondary consumer of the EA services. To sustain EA Capability, you need to focus on why, when, and how EA activities are performed and how the output produced by the team providing the EA Capability is being consumed and by whom.
When the sponsorship is challenging, the focus should be on soft-selling, like communicating the need to subscribe to a retirement or insurance plan. One of the successful methods employed when sponsorship has been insufficient is to develop a roadmap and an implementation plan with reasonable financial projections and present them to executives when annual budget preparations are being initiated. Take time to understand or infer the strategy and direction of the enterprise from annual results, analyst calls, and objective statements of top 20 projects. Use this understanding to build a roadmap for at least one key business unit: if the focus is on improving sales, do it for marketing and sales; if the focus is operational cost management, create one for the operations team. There is heavy cost on acquiring sponsors. In a re-boot scenario, the cost is multi-fold higher.
In EA, there is no right, wrong, or singularity of approach. EA forces itself and its consumers to almost always think of trade-offs; it forces them to look at data to help navigate the chaos. What it achieves is removing the bias for repeatable process and cost optimization. It brings focus to consider all viable alternatives. The change in thinking of organizational leadership is an example of qualitative value addition. All architects in the team should think of developing a set of trade-off criteria that is current with strategic and operational challenges. Providing decision-ready alternatives creates better sponsorship and acceptance of an EA team.
Depending on the organizational culture, the EA team should question a few sponsorship assumptions, if the charter is not clear, and ask itself:
- What kind of financial control should the team providing the EA Capability have?
There are differences in views – from managing just EA’s operational cost (or considering the team providing the EA Capability as capital expense) to sponsoring technology research effort, all the way to validating every initiative for relevance and alignment to organizational goals.
- Should governance be used as a feedback mechanism for both architecture output and project conformance?
- Even though it is suggested earlier in this Guide to use the TOGAF ADM to the extent that immediate value can be realized and iterated, is it the right approach, given the culture of the enterprise?
- Given internal and external forces, should the EA operating model be target architecture or target operating model-driven?
- Should the planning be based on capabilities or process efficiencies and differentiation offered to customers?
- Depending on the charging model in the enterprise, what is the extent to which each of the project execution teams can be taxed for EA engagement?
One of the necessary periodic exercises is to move the focus of the enterprise and the team providing the EA Capability from rigor of documentation and static analysis to operational and strategic business outcomes. Experience shows that such a shift invariably results in increased sponsorship and demand for EA resources.
12.6 Building Community and Mentoring
There are a few things in the enterprise that are everybody’s business – customer goals, quality goals, and EA. Every manager or product developer’s decision has an impact on the goals of the enterprise. Procuring services or products from a supplier introduces friction between objectives and the operating model of the enterprise and that of the service provider. In addition to the risk of engaging in an economic activity, the enterprise is now compounding its risk factors. Given the premise that EA reduces risk impact, objectives of service providers should be assessed periodically.
As the TOGAF ADM cycle is explored in iterations to achieve maturity, develop a playbook to replicate the success with new sets of players, not directly under the team providing the EA Capability’s control. Success and sustainability of the team providing the EA Capability is determined by the belief of the next generation of personnel in the EA Capability team - the mentees of the team and that of the sponsor. Spreading the knowledge and practice of EA to new parts of the enterprise has never hurt the team providing the EA Capability.
Mentoring is one of the techniques to employ to achieve maturity and replication of EA efforts in other parts of the enterprise. Being a trusted advisor is a form of mentoring. Care must be taken to differentiate grooming budding architects and coaching organizational leaders. It is likely that architecture work happens in different parts of the enterprise, with people who don’t have an architect title or are external to the enterprise. Develop deep and continuous engagement with such enthusiasts. Identify what aspects of the architecture work would become differentiators and intellectual property of the enterprise. Promote the differentiators and those who are developing and curating those assets.
Identify the annual training cycles or online courses that the enterprise employs to build talent. Build targeted 20 to 30-minute talks on specific topics to create a pipeline of learning. Depending on the size of the enterprise, augment such training topics with periodic architecture summits. Another approach is consideration for individuals going through technical specialty or architect certifications. Pay attention to what certifications are being pursued – architecture processes or architecture development. Differentiate expertise in architecture method and practice from thought leadership with architecture.
12.7 Tools and Techniques
In simple terms, create a standard operating procedure and execution process for the EA Capability. Tools without interoperability or seamless integration leave room for manual efforts and out-of-sync versions. Out-of-sync versions result in effort cleansing the information instead of effort delivering insights and intelligence. As a Leader, spend time and effort to get the right repository to hold the EA data with considerations for interoperability and reducing rework for downstream work.
Care must be taken to differentiate a project document repository and an EA repository. EA artifacts and project artifacts feed each other. Any tool or process that requires part of the work to be recreated in different tools will lead to failure of adoption.
Categories of documents and repositories to consider are:
- Diagram and visualizing tools for architecture
- Diagram and visualizing tools for solution and technology design
- Standards catalogs (industry, business domain, enterprise) and look-up tools to understand the details of the standard
- Readiness and maturity assessments and progression management tools
- Roadmap management tools, potentially with time series analysis capabilities
- Financial and investment analysis tools
- Architecture evolution management tools
TOGAF® is a registered trademark of The Open Group