Enterprise Architecture is a unique discipline whose origins are still a matter of debate. Many authors routinely bestow that honor on John Zachman’s “Zachman Framework” and believe it laid the foundation for EA as a discipline. However, researchers like Svyatoslav Kotusev claim that the origins of EA precede the Zachman Framework and that EA is a product of IBM’s Business Systems Planning (BSP). If the origins of a discipline are not clear, there may be a lack of consensus on what it actually is. This has plagued EA over the years. There isn’t a universal definition for it. This being the case, one can easily argue that there is consequently no basis for determining how best to practice said discipline.
This book takes the position that the best answer can be found in applying the unique context in which EA will be practiced. There is no one-size-fits-all definition of or best practices for Enterprise Architecture. Professor James Lapalme states that there are three schools of thought on EA, with each having its own definition, scope, and purpose. Firstly, EA may only be concerned with aligning business and IT. Secondly, it may be concerned with architecting the entire enterprise, including IT. Lastly, its concern may be the relationships between the enterprise and its environment. The business should always be clear about why it's choosing EA and what it hopes to achieve.
Best practices are recognized and recommended ways of executing specific processes within your enterprise. For instance, utilizing a SWOT analysis is considered a best practice when determining strategic initiatives. EA does not seek to replace existing best practices but rather assist you in determining how, where, and when they should be used or whether they are delivering the desired outcomes.
When EA is adopted fully, it in itself becomes the final reference for how and when to leverage best practices. It is important to select the most relevant practices in relation to the enterprise and its strategic goals. This is an important factor to highlight because how EA will be practiced will determine what best practices to implement. Enterprises normally face the question of which best practices to adopt. Since an enterprise implements EA according to its unique circumstances, what works for one enterprise may not work for the other. Clearly, the selection of the best practices to take on is one of the more complex parts of EA. The recommendations in this chapter will most likely have to be adjusted to suit your enterprise and address your specific circumstances. For instance, the implementation of EA in your enterprise may require additional change management activities.
Areas such as the infrastructure domain have many best practices to consider; these best practices often address the same area and compete with each other. EA is driven by an organization’s strategic goals and desired future state; this provides the context required to determine what best practices should be implemented. It is imperative for EA to be the overarching reference point for the enterprise.
Up until this point, the book has explored what Enterprise Architecture is, and there's been an overview of a tool that can assist in its implementation. This chapter looks at the recommended ways of carrying out that implementation. Best practices are proven ways of implementing Enterprise Architecture in an efficient way. This chapter provides a general list of best practices which can be implemented, adjusted, or omitted according to the context of the enterprise.
Best Practices for EA
As mentioned, best practices are recognized and recommended ways of executing specific processes within the business. This section goes over the general best practices for EA implementation independent of any specific EA methodology.
Create an EA Charter
An EA charter provides the scope and the reasoning behind your enterprise choosing to implement EA. This is mainly done through detailing the expected benefits of implementing EA and how they will be achieved. The EA charter explicitly identifies all stakeholders and their obligations toward the EA process, acting as an agreement between the EA team and the stakeholders. It clarifies the obligations of the EA team, authority of the EA team, and the relevant decision-making processes.
The EA charter also details the terms of the EA implementation such as what assets will be produced and by when. This is part of defining the criteria for success and allows the EA process to be monitored and evaluated. With that said, what constitutes success will change over time; the EA charter must be reviewed periodically and updated accordingly to ensure its relevance. The EA charter must also cover the risks facing a successful EA implementation ahead of time so that they can be mitigated and monitored.
EA Governance
Governance in the context of EA is the practice of managing and controlling EA on an enterprise level. EA governance generally includes the fundamental aspects of management such as establishing an authoritative hierarchy and sound monitoring processes.
The success or failure of EA depends on the level of oversight, authority, and decision-making power granted to the EA team in discharging their duties. Developing a clear chain of command is a nonnegotiable aspect of EA implementation. Naturally, the EA team’s authority should span the entire enterprise and support them in implementing EA across all domains (business, information, infrastructure). It is also recommended to have a wide range of participants that represent different interests as part of the EA team. For instance, leaders from the business domain are less likely to be resistant to change if they have played a part in in defining such a change.
A formal EA Program Management Office should be set up to house the EA team. The EA Program Management Office should be backed by executive support and stakeholder cooperation. The EA Program Management Office should be headed by the Chief Enterprise Architect. The Chief Enterprise Architect must lead collaborative exercises that determine the standards and best practices to be followed throughout the enterprise to achieve the desired future state.
EA governance should not become a burden to the business. It should be “lightweight” and lean on already existing governance procedures within your enterprise. The governance process should clearly identify who is responsible for architecture and compliance decisions as well as the possible disciplinary actions to be faced if need be. One of the goals of EA is to make the business more agile; this includes leaving room to make some exceptions in the governance process.
It is important to note that the EA team should comprise individuals with different skillsets (i.e., modelling, EA governance, EA asset administration, etc.) but common talents (strong communicators, innovators, leadership, etc.).
Business Strategy As a Starting Point
The enterprise’s business strategy essentially represents what the business aims to achieve and how it aims to achieve it. It is the business strategy that drives the articulation of the enterprise’s desired future state. It is best practice to start by developing a thorough understanding of the enterprise’s business strategy because EA exists to support the goals and objectives of the business strategy. Showing how EA supports business strategy plays a key role in winning over the executive of the enterprise who are mainly concerned with the execution of business strategy.
The business strategy also offers a focal point to employ a shared strategy. EA has a lot to do with the enterprise moving in synergy toward a common goal. EA should be founded upon the business strategy to guide the enterprise’s decision making, processes, and practices.
Implement a Communications Plan
Each enterprise has its own way of comprehensively disseminating information, but special care should be taken in the case of EA as poor communication tends to be a stumbling block in most instances. The three preceding steps produce assets whose information must be clearly communicated to all stakeholders. It is a best practice to develop a communications plan to share the benefits, scope, and objectives of EA.
Key stakeholders must be identified alongside the targeted messaging that addresses their concerns. The EA team should detail all communication methods that are to be utilized (online meetings, newsletters, etc.) and categorize the most effective communication methods for each stakeholder group. The communications plan should outline specific timelines and responsibilities for communications procedures as well as a feedback process to monitor the execution of the communications plan.
Project-Based Approach
The enterprise is more flexible and can adapt to change in its environment through projects that address unforeseen circumstances.
Projects allow for the meeting of short-term goals which helps show the value of EA to stakeholders through improving the value to market cycle.
Projects allow for a quicker and more consistent feedback cycle.
The activity planning and resourcing for EA is simplified, better estimated, and better coordinated.
Each project can have a dedicated specialist project manager which frees the EA team to focus on enterprise-wide duties.
Lastly, structuring the EA as iterative projects allows for agile adoption. At EA’s inception, IT projects ran in long cycles spanning years. That has progressively changed with agile methods shortening development time dramatically. Agile methodologies promote collaboration, continuous feedback, and rapid value creation.
Select a Framework
A framework is responsible for structuring the EA process and therefore defines its scope. It depicts the architecture and its subdomains, therefore forming a basis for determining boundaries. These boundaries allow for the clear segmentation of tasks, responsibilities, and stakeholders. Furthermore, it can be used to define the relationships between architectural domains. For instance, it can depict how an information system in the information architecture is critical to business processes in the business architecture. This kind of structuring allows a common enterprise-wide perspective of all the subdomains within the architecture.
TOGAF ADM
Zachman Framework
Department of Defense Architecture Framework (DoDAF)
Gartner Enterprise Architecture Framework
Select a Methodology
An EA methodology speaks to the actual execution of the EA process. It provides a detailed step-by-step action plan for creating the EA program, creating the documentation, creating the future and current views of the enterprise, and, lastly, maintaining and utilizing EA assets. EA assets are the resulting products of the EA process including items such as documentation. For instance, the EA charter is one of the products of creating the EA program. Each subdomain presented in the chosen framework has EA assets that will be produced through the execution of the prescribed steps in the methodology. An example would be a network connectivity diagram as part of the EA assets under the infrastructure architecture or a use case diagram under the business architecture.
Central Information Repository
All EA assets must be stored in a central repository and accessible by all relevant parties. An online storage point within the enterprise’s internal network is ideal. The repository must be visually presented in a logical way that enables easy navigation for users. Related EA assets should be linked together and consumable from one view.
Define the Future State First
Business strategy by nature speaks to the future of your enterprise. The main goal of EA is to facilitate change toward the achievement of strategic goals. The business would not be implementing EA if the current state of the business was meeting strategic goals. In essence, the only use of defining the current state of the organization is to estimate the effort that is required to accomplish the desired future state, whereas the future state forms the basis of what actually has to be done. Focusing on the future state means the business strategy will stay top of mind as opposed to being bogged down to the current state of the enterprise which is not meeting strategic goals.
Monitor the EA Process
Monitoring the EA process may bring some anxiety to the EA team, but it is a critical best practice. It is important to define metrics at the beginning of the EA process to ensure that EA is delivering business value. The first step to achieving this is through genuinely understanding and taking on all stakeholder concerns. The metrics to monitor EA must align with stakeholder concerns; otherwise, what may seem like success to the EA team theoretically may not mean anything practically. In essence, you are translating stakeholder expectations into tangible and measurable goals.
The EA team should measure and report on progress regularly to ensure that the EA process remains effective. Measuring progress enables your enterprise to make decisions based on reliable data and also allows you to innovatively tackle any issues that may have been exposed through the monitoring process. There is no template of metrics that can apply here because enterprises differ in their goals, strategies, and levels of maturity.
Since EA is a discipline that predominantly addresses how your enterprise will adapt to the future, your EA process itself must evolve. The maturity level of your EA process must be assessed on an annual basis as well as conducting a reevaluation of the measurement metrics in place. What areas of your EA process can be improved to make it more effective? The answers to this question should be translated into an action plan to address these areas for improvement.
Implement a Comprehensive Change Management Strategy
The adoption of EA is a radical change for most enterprises and may initially seem like it is in opposition to the decentralization of power within your enterprise. Managers may feel that the control over their specific domain is being taken away. A comprehensive change management strategy has to be implemented; having a dedicated resource to this effect is considered best practice. Beyond the stakeholders, the enterprise itself may be plagued with siloed processes and systems that have to be done away to enable a truly enterprise-wide approach to be implemented.
The EA process involves an analysis of future and current states of the organization. This may result in exposing the shortcomings of particular departments or individual staff members. Naturally, you can expect some resistance or lack of cooperation. It should be continually communicated that EA is there for the improvement of the organization and therefore will not affect any area that is functioning accordingly.
Articulate and Measure the Value of EA Possible Challenges
Enterprise Architecture can be a resource-heavy endeavor in terms of time, people, and financial resources, to mention a few. These are resources that could be directed to other parts of the enterprise that yield quicker results. The EA team must be cognizant of the fact that they’re always in competition with the enterprise’s other initiatives. The first way of dealing with this competition is by articulating the value proposition of EA and ensuring that it addresses stakeholder concerns. Secondly, put forward metrics to measure success on a consistent basis so that stakeholders remain informed on progress.
Benefits of Best Practices for EA
Informed decision making – EA provides an enterprise-wide view of the business that supports business decision making. Decision makers have insight into how a decision in one domain affects other domains.
Business and IT alignment – Implementing best practices ensures that the importance of aligning the EA endeavor with business goals.
Agility – EA is based on frameworks. There may be an inclination to strictly stick to frameworks that may result in the organization becoming rigid. EA best practices ensure that your organization remains flexible and adaptable to change.
Improved return on investment for projects executed within the EA context. EA best practices allow for the better control and monitoring of projects which leads to saving costs.
EA best practices prescribe steps that ensure that your EA process undergoes continuous improvement on an annual basis. Best practices enable your enterprise to avoid common pitfalls (such as not aligning the EA endeavor with organizational goals) ahead of time because they have been developed from tangible EA experience. These common pitfalls include
EA best practices endorse the adoption of a framework that provides a uniform and enterprise-wide approach of taking on change. This promotes synergy throughout the enterprise which eliminates the old age problem of operating in silos. Lastly, best practices offer a starting point for the level of skills and knowledge required of the EA team.
Things to Avoid
As mentioned in the section “Benefits of Best Practices for EA,” there are many common pitfalls you can encounter on your EA journey. Some of them have been listed as follows alongside a short explanation to assist you in being aware of them during the EA process:
Using complex technical jargon – As technical people, the EA team may incorporate complicated jargon that only they understand, overlooking the fact that EA must be understood by all stakeholders to ensure maximum adoption. Utilize plain language to the greatest extent possible.
Neglecting business strategy – Enterprise Architecture is generally seen as a highly technical endeavor, which it is; however, it is a technical endeavor implemented to enable the realization of business goals. Business strategy plays the important role of focusing on the EA process and must always be an overarching consideration. This will also ensure that the EA process remains linked to budgetary concerns.
Being too rigid – Frameworks and methodologies have their rightful place but very rarely will a framework or methodology suit your enterprise perfectly. Frameworks and methodologies serve as a point of reference to promote a common understanding of what is to be accomplished while maintaining a certain level of standards. However, this does not override scenarios where the framework or methodology must be adapted to suit the environmental realities of the organization.
Working in silos – The EA team should never find themselves isolated from stakeholders and neither should any EA project be undertaken without a thorough assessment of enterprise-wide consequences. Make sure to include stakeholders representing various concerns in the EA process.
Analysis paralysis – As much as EA has a lot to do with research and analysis, it shouldn’t become a hindrance to execution. Always remember that the ultimate goal of EA is to transition the enterprise to a future state.
Overemphasis on the current state – Never spend too much time or overstate the influence of the current state on achieving the future state. More time should be dedicated to articulating where the enterprise would like to go strategically.
Doing everything at once – Initially, there may be a tendency to tackle different issues at once. This is likely to result in nothing getting done. Try to prioritize the items that are key to the enterprise and will readily show the value of EA to your enterprise.
Summary
Chapter 1 introduced the idea of enterprise architecture being both a process and the product of that process. This chapter introduced how there are best practices to implement Enterprise Architecture. Furthermore, Enterprise Architecture can be considered a best practice in itself in relation to facilitating organizational change. The first seven chapters of this book addressed the latter.
Hiring an experienced Chief Enterprise Architect who heads up the EA Program Management Office
Securing stakeholder cooperation
Developing a project charter
Establishing the EA’s value proposition from the onset
Having an engaged project sponsor that you always keep in the loop
The prescribed steps have been developed through analyzing tangible experience and extensive research. However, it is important to factor in that you will most likely have to pick and choose the best practices to adopt, as well as adapt them to suit your enterprise’s specific context. This chapter closes by highlighting common challenges and pitfalls that are faced during the EA process to enable you to avoid them ahead of time or identify them if they do arise.