 | Level: Intermediate Jeff Egan (jeff.d.egan@gmail.com), Ecommerce consultant and freelance writer
05 Sep 2006 Discover how to use The Open Group Architecture Framework (TOGAF) and overcome potential obstacles you can encounter when building an enterprise architecture. Getting started
When considering the implementation of an enterprise architecture, you can begin to feel overwhelmed with all the pieces. This article walks you through how to begin that process by leveraging an existing architectural model like The Open Group Architecture Framework (TOGAF).
There is often intense discussion in organizations about whether a formal documentation process of the enterprise development phases is actually productive. The reality is, however, that you probably already do the majority of these steps anyway, perhaps just not in a structured way. Using a reference framework like TOGAF helps to identify the steps involved and enumerates them so that a common list of the pieces exists. This list enables an enterprise to identify what might be missing from its current practices. Perhaps more important, it also provides a common taxonomy with which to reference enterprise architectures. So, if you don't have an official enterprise architecture in place, let's look at the steps you might go through to put one in place. Let's use the TOGAF framework as the tool to help us get there.
Assessing cultural fit
Before getting too involved in the process, one of the first things that needs to be identified is cultural fit. That is, considering your organization's culture, is developing an enterprise architecture a hard sell or is it an intuitive next step?
If your current enterprise consists of a highly decentralized set of business processes, groups, and systems, it will require a little more up-front effort to sell the benefits of an enterprise architecture, but that does not mean it cannot be done. You may have to start small, and since any size organization can adopt the principals of TOGAF, it may be necessary to start with one piece of the enterprise and add other groups as the benefits become demonstrable to them. On the other hand, if your organization is highly centralized, with well-documented and defined business processes and systems, the road to establishing an enterprise architecture may be a shorter, smoother one.
Medium Manufacturing: A mid-sized company
For the purpose of this exercise, take a look at a fictional mid-sized manufacturing company, which we will call Medium Manufacturing, or MM. Among MM's systems that need to be defined by the architecture are design and planning tools for product creation, supply chain management tools and systems, as well as a financial system. Of course, MM could include many others, but for simplicity's sake, we'll limit ourselves to these.
MM has grown organically duringr the past decade. Its tools and practices are highly decentralized, with each business group controlling its own tool selection and processes. As a result, MM has developed many redundant systems, duplicate and conflicting data resides everywhere, and development methodologies and tools differ widely. However, business and IT managers have recognized the need for a more structured approach and are agreed on trying to establish an enterprise architecture.
This last point is not a trivial observation. Depending on the business culture, persuading people that an enterprise architecture is needed may well be the hardest part of creating one.
Using the TOGAF model to get started
Now that we have the context set, the first activity is what the TOGAF Architectural Development Model (ADM) calls the preliminary phase. The following list is taken straight from the TOGAF documentation. (See Resources for a link to TOGAF materials). Its objectives are fairly simple and include:
- Ensuring that everyone who will be involved in, or benefit from this approach, is committed to the success of the architectural process
- Defining the architecture principles that will inform the constraints on any architecture work
- Defining "architecture footprint" for the organization -- the people responsible for performing architecture work, where they are located, and their responsibilities
- Defining the scope and assumptions (particularly in a federated architecture environment)
- Defining the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM)
- Setting up and monitoring a process (normally including a pilot project) to confirm the fitness for purpose of the defined framework
- If necessary, defining a set of criteria for evaluating architecture tools, repositories, and repository management processes to be used to capture, publish, and maintain architecture artifacts
Using these guidelines, let's take a look again at MM. The first step is to identify the MM corporate culture. We find that the MM culture is one in which decisions are currently made in a decentralized fashion, with each business group largely able to make autonomous decisions. As noted previously, we have already succeeded in convincing MM that an enterprise architecture will benefit the company. Doing so will decrease the time to market for new initiatives. It will also decrease costs as MM finds ways to reuse new and existing solutions and filters out of the to-do list projects that are less important to the enterprise.
Getting the right people involved
Now that management is aligned and the level of corporate culture is assessed, it's time to identify key players within business and IT functions who need to participate in architectural decisions. Since this is a cultural shift for this company, we need to take great care that the right players are identified, involved, and enabled to influence the direction of the enterprise architecture group. This is because most reforms of this nature do not succeed because key cultural participants are not involved early enough in the process.
It is also imperative that the formation of an enterprise architecture has the support of key business leaders and not just IT. This is especially true of an organization -- like MM -- that is not typically known for being an IT company. Again, be aware of your company's culture and adapt accordingly. In the case of MM, key architects, engineers, business process experts, and business managers will need to be involved from the supply chain, finance, and product creation teams to ensure success across the enterprise.
Establishing architectural principles
Once the key members are identified, the TOGAF ADM makes the next steps fairly straightforward. First, key guiding principles need to be identified that will be the steward to all future architectural decisions. These will not be unalterable statements carved in stone, but will be enduring and simple principles that can guide MM. They will need to evolve with the direction and goals of the company.
To that end, TOGAF suggests that architectural principles be based on company principles. For example, if the company's mission statement or guiding principles are based on innovation, then it becomes difficult to have an architectural principle that recommends solutions be based on off-the-shelf software with little or no customization. While the formation of business principles lies outside the creation of architectural principles, TOGAF suggests it is good to have the architectural principles restate or cross-reference business principles. Ultimately, the architectural review process (part of TOGAF's ADM) will need to ensure that projects meet or align with both architectural and business principles.
Furthermore, architectural principles need to cover the full range of the architectural spectrum. TOGAF states there are four such areas:
- Business architecture
- Data architecture
- Application architecture
- Technology architecture
An example principle might revolve around the need to design systems with business continuity in mind: the principle is short and easily defined, a broader description is given, and the rationale and implications are described. See Listing 1, taken from the TOGAF documentation. These statements allow everyone to understand the broader implications behind the principles and eliminate ambiguity. Principles should not be so numerous and broad that they contradict. They should cover key areas of business goals alignment, data principles, application principles, and technical principles.
Listing 1. Sample architectural principle
EXAMPLE:
Principle: Business Continuity
Statement: Enterprise operations are maintained in spite of system
interruptions.
Rationale: As system operations become more pervasive, we become more
dependent on them, therefore, we must consider the reliability of such
systems throughout their design and use. Business premises throughout the
enterprise must be provided the capability to continue their business
functions regardless of external events. Hardware failure, natural
disasters, and data corruption should not be allowed to disrupt or stop
enterprise activities. The enterprise business functions must be capable of
operating on alternative information delivery mechanisms.
Implications:
Dependency on shared system applications mandates that the risks of business
interruption must be established in advance and managed. Management includes,
but is not limited to, periodic reviews, testing for vulnerability and
exposure, or designing mission-critical services to assure business function
continuity through redundant or alternative capabilities.
Recoverability, redundancy, and maintainability should be addressed at the
time of design.
Applications must be assessed for criticality and impact on the enterprise
mission, in order to determine what level of continuity is required and what
corresponding recovery plan is necessary.
|
Using the TOGAF ADM to create architectural processes
As soon as the people and principles are in place, we need to establish a set of architectural processes. These processes establish how development is conducted in the enterprise. This is where leveraging a framework like TOGAF's Architectural Development Model (ADM) can be highly advantageous, because the framework for these sets of processes already exists and is well defined. The ADM consists of eight phases, which are described in the TOGAF introdution article (see Resources). Each phase requires a number of processes that will have to be created and adapted by each enterprise so that they align with business culture and principles.
The creation of these processes will be iterative. It is unlikely that a single organization will put into place a complete set of processes to begin with. Nor is it expected that the processes remain static. Rather, the expectation is that the processes will be more evolutionary in nature, adjusting to fit corporate culture and business principles. For those organizations that already have well-documented processes, the TOGAF ADM is designed to be adaptable to existing frameworks and processes. Again, the benefit of referencing a framework like TOGAF is that it is designed to be comprehensive enough to fit most, if not all, enterprises. However, while customization will most likely be needed, the TOGAF model helps ensure that all the details are covered.
Adapting TOGAF to your enterprise
When establishing an enterprise architecture, it may also be necessary to conduct the phases in a different order. For example, neither the MM IT systems nor its business practices are particularly well documented. Therefore, MM's architecture team decides that before setting out an architectural vision (phase A), it will complete one round of documenting business and technology architectures, identify opportunities (phases B,D, and E), and then use the information gathered to guide their architectural vision.
After the documentation is in place, MM's architecture team decides that its systems are too highly customized. The company has legacy systems running on outdated and unsupported platforms as a result. It also has seven order-entry systems, differing by region and business group. It decides that one of their architectural principles will be to use customization wisely. As a result, it will become necessary to spend time tuning the business architecture (phase B). MM also has many other processes already in place, some of which will be highly customized for a particular business unit, so the team may spend several iterations between developing a business architecture and an architectural vision before including the other phases of the ADM. As the team works to develop the overall processes that will guide the ADM, it will, of course, leverage the best practices of each group and strive to standardize on one set of processes.
Here you can see the potential payoffs of an enterprise architecture. When systems and processes are derived from the same base set of guiding principles, it is much simpler for staff to move from project to project.
Eventually all processes will have to be tuned to meet the resources that a company can commit to the effort. Large enterprises will have more resources to deal with the increased complexities of their systems. Small- to medium-sized companies will need to strike a balance between the resources needed to establish and maintain an enterprise architecture group and the resources needed to implement or maintain systems.
Fortunately, TOGAF provides guidelines about how to define the scope of an enterprise architectural foundation. Remember that in our example, MM decided to limit the scope of the enterprise to just three systems: product creation, supply chain, and financials. This is one way to limit the scope of architectural activity. Another would be to restrict the number of architectural domains that are considered (for example, business, data, applications, and infrastructure). MM decides not only to limit the reach of the architecture to just three systems, but also to tackle only business and data architectures in the first pass.
Assessing other needs: resources beyond people and processes
There are two additional needs that accompany the establishment of a foundational architecture. First is the need to create a repository of resources that can be leveraged by the architectural team as projects flow through for approval. The resources consist of a repository of patterns, tools, skills, and contracts that are used in each phase of the ADM. For example, to initiate a project request to the architectural team, a preliminary statement of work (SOW) may be required. If so, then the current working copy of the SOW needs to be accessible. A current copy of the architectural principles, previous case studies, in-use architectural patterns, and other informational resources need to be accessible to the appropriate team members.
A process must also be in place for managing the changes to those documents. The Open Group manages a Standards Information Base that contains extensive reference material that can be part of the resource base we just mentioned. See
Resources for a link to the Open Group's Standards Information Base. According to the TOGAF documentation, the Standards Information Base has three main uses:
- Architecture development: For an organization that is creating an architecture for its information systems, the Standards Information Base provides a valuable source of information about standards that can be used to populate the architecture.
- Acquisition/Procurement: The Standards Information Base helps procurement ensure that all relevant architectural process has been followed and that requirements have been met. (For example, the retail branch of MM might want an order-entry system and submit a request to Procurement. Using information from the standards base, the procurement team can ensure that all relevant architectural concerns have been addressed in the new contract.)
- General information: The Standards Information Base can be a source of information about relevant IT standards, for use by anyone, at any time.
Creating a technical reference model
To have consistency in an enterprise, you need a common way to describe and model different architectures. The TOGAF standard provides a Technical Reference Model (TRM) that can be used or modified to create a standard method for documenting systems and architectures within a given enterprise. The objective of the TOGAF TRM is to provide a widely accepted core taxonomy and an appropriate visual representation of that taxonomy. In other words, it helps make sure that the information that is put into the SIB follows a common taxonomy. Other architectural models -- including taxonomies and graphics -- are not only possible, but may be preferable for some enterprises. Similarly, an enterprise may prefer to represent the TOGAF taxonomy (or its own taxonomy) using a different form of graphic that better captures legacy concepts and proves easier for internal communication purposes. The core of TOGAF is its Architecture Development Method: the TRM and the SIB are tools used in applying the ADM in the development of specific architectures. If consistency between TRM and SIB are maintained, the TOGAF ADM is valid whatever the choice of specific taxonomy, TRM graphic, or SIB toolset.
Since MM does not have an existing common TRM in place, the team will choose to leverage the pieces of the TOGAF TRM that best fit its immediate needs. Additional documents and processes will also be created and put in MM's current version control system. Access to these key resources will be provided through the existing company portal. An architectural board will be established and a project identified to pilot the new processes.
Medium Manufacturing (MM) now has three things it did not have before. First, it has a corporate commitment to an enterprise architecture, which includes the creation of an architectural board with key business leaders. Second, it has a set of living processes by which projects will be identified, approved, and run within the company. Third, it has a Technical Reference Model and Standard Information Base to store and centralize information. Of course, none of these are set in stone; as projects get submitted, approved, and executed, adjustments will be identified and changes made and communicated. However, Medium Manufacturing is now well on its way to reaping the benefits that an enterprise architecture can bring.
Summary
Foundational architectures are not created overnight, so there are many important decisions that each architect will have to make. However, the TOGAF standard can significantly speed the process by providing a framework that is flexible enough to absorb change and modification, but detailed and complete enough to help organizations of all sizes. As our company MM takes its first project through newly formed governance processes, lessons will be learned and improvements made. It is inevitable that some decisions will not always work, or what worked the first time will cease to be effective. The model will need to continually evolve to meet the new challenges. The key is to start small and work iteratively to establish improvements and to leverage an existing framework like TOGAF to get you rolling down the enterprise architecture road more quickly.
Resources
About the author | | | Jeff Egan has been an architect for Nike's Direct to Consumer group and has been involved in Internet technologies for more than 10 years. He helped establish the Utah Education Network's public Internet infrastructure, which connects all Utah schools to the Internet. He is currently an e-commerce consultant and freelance writer. Contact Jeff at jeff.d.egan@gmail.com. |
Rate this page
| |
