Every organization has one. Sometimes it is complex and rapidly changing; sometimes it is relatively straightforward and stable. It supports an organization of 50,000 employees with billions of dollars in revenues or 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 enterprise architecture is viewed as an abstract concept that has little value. This view is false. 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 information technology, change a business process, decommission an application or conclude a merger or acquisition. Wouldn't it be great if you could figure out all the different changes you must make to business processes, roles and responsibilities, databases, applications and the underlying information technologies at the click of a mouse? With an EA, the impact of change can be easier to articulate and can be achieved with a much faster turnaround 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 interrelated activities to complete work and deliver value. A broad range of information technologies is enabling these activities. 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 enterprise architecture 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, as well as
  • The relationships and dependencies between them.

Figure 1 shows the conceptual relationships between components of the EA.

Figure 1: Conceptual Relationships Between EA Components

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 enterprise architecture 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!

How does an organization go about implementing an enterprise architecture? Following is a framework of how to get started:

  • Form a cross-functional working team with representative stakeholders from across the organization. A commonsense approach must be taken to determine who should be part of the team and how to solicit input throughout the organization. A team no larger than seven or eight should be sufficient, even for the largest and most complex organizations.
  • Define what is meant by EA. Define the 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.
  • Appoint an EA champion whose job is to promote the initiative throughout the organization.
  • Establish a cross-organizational steering committee to serve as a clearinghouse for the orderly resolution of issues. Again, keep the size of this committee to seven or eight people at the most.
  • Determine an appropriate architectural framework (Zachman, The Open Group Architecture Framework [TOGAF], ARIS Method, etc.) to guide the organization's development of the EA.
  • Select an integrated architectural modeling tool 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.
  • Define architectural modeling standards and best practices to guide the development of architectural models.
  • Create a group of framework models with logical placeholders for more detailed development at a later date.
  • Identify candidate projects or areas of interest. Start by identifying the project drivers (reducing operating costs, streamlining an inefficient process, improving quality, enhancing capacity, etc.) and then create a group of project-centric models that are later incorporated into the EA framework.
  • As each project completes, harvest the benefits! Quantify the benefits that each project and the organization have attained from the ongoing development of the EA framework, such as 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 or faster change delivery.

The future holds heightened expectations with the emergence of service-oriented architecture (SOA), Web services, composite applications and enterprise application integration (EAI), just to name a few. How can these new technologies be incorporated into your organization? What is the best means of introducing these technologies, and in what order should they occur? What is the impact, and who is affected? These are just some of the questions for which an EA can facilitate meaningful answers.
Final words of advice: first and foremost, recognize that anything worthwhile takes effort. The benefits can be significant, but an ongoing 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 enterprise architecture to start accruing benefits. Start in small manageable phases and build the enterprise architecture over time. Thirdly, recognize that the value of the enterprise architecture diminishes rapidly when it is not kept up to date. Ongoing maintenance is essential to the sustainment of benefits accrual.

Although we are obviously passionate advocates of enterprise architecture, we would be remiss if we did not balance our passion by admitting that enterprise architecture is not a cure-all for all of the challenges facing IT or the organization. That said, an enterprise architecture will enhance the organization's ability to react more quickly to change, embrace new business opportunities and prioritize. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access