Every organization has one. Sometimes it’s complex and rapidly changing; sometimes it’s relatively straightforward and stable. It supports an organization of 50,000 employees with billions of dollars in revenues or one with 100 employees with modest revenues. Whether or not it is formally documented and understood, it exists. What we are referring to is the Enterprise Architecture (EA). In most organizations, the EA is viewed as an abstract concept that has little value. We believe that in a world of rapid change, the Enterprise Architecture is real, has significant benefits and is more important now than ever.
Picture this: your organization wants to embrace a new technology, change a business process, decommission an application, or conclude a merger. Wouldn’t it be great if you could figure out all of the resulting changes you would have to make to business processes, roles and responsibilities, databases, applications and the underlying information technologies at the click of a mouse? Well, with an EA, the impact of change can be easier to articulate and can be achieved in a much faster turn-around than traditional methods for impact assessment and gap analysis. An EA provides the blueprint of the current state, helps to identify the specific areas most affected by the change and then sets up a blueprint to transition to the future state.
Every organization conducts an array of inter-related activities to complete work and deliver value. Enabling these activities is a broad range of information technologies. Collectively, all of these individual components make up the organization’s architectures, but understanding each of them and their relationships presents a complex and significant challenge. The Enterprise Architecture helps to make sense of these complexities and then describes the relationships and dependencies that exist between them. An EA provides the framework to logically organize and model the definitions of an organization by describing what the organization does; how it does it; who does it; what data is used and where it is stored; what information technologies are employed and how they are used; and the relationships and dependencies between them.
An Enterprise Architecture is all about timing. For example, when an organization changes its business processes, it can better understand the impact of change by readily identifying the components of the EA that will be affected. The organization can quickly understand what needs to change, how to change it, and is now in a position to divert resources to enable the change. It is what organizations dream about!
10 steps to implementing the EA
So how does an organization go about implementing an EA? Here are ten steps for establishing a successful EA framework:
1. Form a cross-functional working team with representative stakeholders from across the organization. A common-sense approach needs to be taken here to determine who should be part of the team and how to solicit input throughout the organization. A team of no more than seven or eight should be sufficient, even for large and complex organizations.
2. Define what is meant by Enterprise Architecture. This defines scope and the mandate for the team. Define the targeted benefits and metrics the organization wants to achieve from its investment in the EA initiative.
3. Appoint a champion whose job is to promote the initiative throughout the organization.
4. Establish a cross-organizational steering committee to serve as a clearing house for the orderly resolution of issues. Again, keep the size of this committee to around seven or eight at the most.
5. Determine an appropriate architectural framework (Zachman, TOGAF, ARIS Method, etc.) to guide the organization’s development of the EA.
6. Select an integrated architectural modeling tool (ARIS, Mega, System Architect, etc.) to serve as the repository for process, data, organizational, technology and application architectural models. Ensure the tool is capable of supporting the selected architectural framework.
7. Define architectural modeling standards and best practices to guide the development of architectural models.
8. Create a group of framework models with logical placeholders for more detailed development at a later date.
9. Identify candidate projects or areas of interest. Start by identifying the project drivers (e.g., reducing operating costs, streamlining an inefficient process, improving quality, enhancing capacity) and then create a group of projectcentric models that are later incorporated into the EA framework.
10. As each project is completed, harvest the benefits. Quantify the benefits each project and the organization have attained from the on-going development of the EA framework. These can include: faster impact and gap analysis; ability to conduct what-if scenarios to evaluate alternate courses of action; redesigned business processes that have tangibly reduced costs when compared to original process design; adoption of industry standards and best practices; introduction of a new information technology that tangibly increases capacity and improves performance; cost savings by selecting the best alternative for the organization; cost avoidance; faster change delivery.
The future holds heightened expectations with the emergence of Service Oriented Architecture (S0A), Web services, composite applications and EA Integration (EAI), to name a few.
How can these new technologies be incorporated into your organization? What is the best means of introducing them, and in what order should they occur? What is the impact and who is affected? These are just some of the questions that an EA can go a long way in providing answers for.
An Enterprise Architecture provides the blueprint of current state and helps to identify the specific areas most affected by the change and then sets up a blueprint to transition to the future state.
A few words of advice
First and foremost, recognize that anything worthwhile takes effort. An on-going commitment to the Enterprise Architecture’s development and maintenance effort must be understood at the beginning.
Secondly, you don’t need to define the entire EA to start accruing benefits. Start in small manageable phases and build the EA up over time.
Thirdly, recognize that the value of the EA diminishes rapidly when it is not kept up-to-date. Ongoing maintenance is essential for there to be continuing benefits.
Although we are passionate advocates of EA, we would be remiss if we did not acknowledge that it is not a panacea for all of the challenges facing IT or the organization. What it will do is enhance the IT department’s and the organization’s ability to react more quickly to change and embrace new business opportunities and priorities.
In a world of rapid change, the EA is real, has significant benefits and is more important than ever.
QuickLink: 055670
–Neil Ross is a Partner in IT Architects, a Calgary-based consulting firm specializing in Enterprise Architecture and Enterprise Application Integration. He can be contacted at <email na
