The most valuable assets of any organization are often its business processes, applications, and data design—especially for organizations that develop their own software systems, which can represent an investment of millions of dollars. Most often, however, the critical information about these prime resources is trapped in the heads of a few key individuals within the organization. Consequently, that information is available only when these people are available, and vanishes from the organization when they do. The solution is to capture this information in a corporate repository, typically in the form of data, process, and software models. This article describes the structure, organization, and management of an enterprise architecture repository.
An enterprise architecture repository is much like your local public library. The information in the library is stored in many forms, such as books, reference indices, tapes, CDs, photographs, maps, journals, papers, and magazines. The value of the library is not simply in the materials themselves—virtually any patron using a combination of a uniform organizational scheme and standard indices can rapidly locate and access any particular item. If, by contrast, everything was in a pile on the main floor, it would significantly reduce the usefulness of the library by making the search for materials virtually impossible. Likewise, even with materials placed in categories, if patrons are permitted to place materials anywhere they choose, the situation is almost as bad as the big pile—nothing can be found without an extensive and painstaking search. Yet, this situation is found in many large companies, especially those involved in software development.
Documentation is written, reviewed, approved, then saved to a shared drive. Very rapidly, it is lost to the data wilderness for all time. Models (if they are even created) are saved to a local or shared drive, used for a time, and allowed to fall into obsolescence. In actuality, these materials represent a large investment of money, effort, and time; as such, they are extremely valuable corporate assets. Permitting these materials to fall into disuse is the same as throwing money into the wind—it will never return. The main culprit is time—time to find the materials, time to ensure that they're accurate, time to update and store the items. Given the usual delivery stress for projects, it's faster and easier simply to recreate the document or model—and then do it again, and again, and again.
To stop this cycle, materials that are intended for reuse (such as requirements, models, or design documents) must be treated as reusable assets. A reusable item is stored according to a well-defined categorization, can be rapidly located, and is treated as a valued corporate asset rather than a disposable project artifact. For example, a use-case document may be created for a system under development, but if it's not stored in a repository, it's unlikely to be used for the next development cycle—especially if the cycles are separated by a great deal of time. This is the purpose of the enterprise architecture repository: It provides a structure, index, and management scheme all rolled into one. All that's needed is some form of file version-control system such as IBM® Rational® ClearCase® or Concurrent Version System (CVS) to allow permanent file access and control. The first step in establishing a repository is to set up a stable structure that supports the business operations of the organization. The second step is to establish a set of procedures and processes to manage and maintain the library over time.
Building a model structure and implementing the file-control system is simply the first part of establishing an enterprise architecture repository. The more difficult task is to manage and maintain that structure over time, especially as the number of modelers increases. Over time, the number and speed of changes introduced into the structure and content of the repository will gradually increase, as will the number of team members who want to find and review materials. Therefore, it's critically important to establish a responsible party to manage all changes and monitor the repository for consistency.
To this end, introduce three new organizational roles, shown in Table 1.
Table 1. Model management roles
| Role | Responsibility |
|---|---|
| Interested party | Anyone in the organization interested in adding, updating, or modifying materials under version control in the repository |
| Repository manager | Individual responsible for managing and maintaining the structure of a major section of the repository (for example, application architecture) |
| Model owner | Individual responsible for management and oversight of a particular model area (for example, a specific application) |
The repository manager is ultimately responsible for the structure of the repository. As found in any library, the patrons cannot be allowed to decide where and when materials will be stored. The repository manager acts as chief librarian to accept and review requests for changes, additions, or rearrangement of the core repository structure. If the repository manager agrees with the change, it can be scheduled for implementation and communication to all repository patrons. In most cases, these kinds of decisions are of an architectural nature and so are best judged by an architecture team. Thus, at least initially, the assigned repository manager should come from the appropriate system or business architecture team.
In contrast, the model owner is responsible for the content of the repository. For example, an application architect is responsible for the model structure and content of a particular application. The model owner works closely with the repository manager to establish the initial model structure, which is of particular interest in the event the model files are under source control. To promote consistency, each repository area (that is, application, data, business, or service) should have a common model template that each team can use to establish the initial model.
All content in the repository must be protected by some from of version control. Depending on the implementation tool, this control is provided by a database, a file-control system, or a file version-control system. One particularly powerful combination involves the use of Rational ClearCase, Rational Software Manager, and Rational RequisitePro® to establish the repository for requirements, models, and other architecturally relevant artifacts. In this case, the model files from Rational Software Modeler are under Rational ClearCase control and match up structurally with the requirements saved into Rational RequisitePro. The close integration of these tools can be leveraged to create a single, seamless model for business, application, service, and data requirements. Using a version-control system for part or all of the repository also makes it possible to have parallel development on the same system model by using a branching-and-merge strategy.
Any organization can gain value from an enterprise architecture repository, but those that focus on software system development will gain the most. With the exception of code, these organizations often have little or no formal way to manage development artifacts, such as documents and models. The result is similar to the aforementioned pile of books: a multitude of documents on shared drives under cryptic file or folder names that are lucky ever to see the light of day. This situation can be largely avoided by adding a certain amount of discipline and rigor to the development process and creating a formal repository to manage and house all long-lived development artifacts.
Figure 1 shows the top-level structure for a typical enterprise architecture. Note the four core framework areas: the application architecture, the business process architecture, the data architecture, and the service-oriented architecture (SOA). In addition, there may be one or more additional areas to support specific business needs, such as an area to capture physical plant models in support of development efforts for a hypothetical telecommunications firm. This additional supporting area—perhaps named Physical Structure—would be used to store models on the network hardware, cabling, physical plant, and other infrastructure information.
Figure 1. Enterprise architecture top-level structure
The implementation of the enterprise architecture framework depends on the tools used to capture the model information. For example, a requirements-management process using Rational RequisitePro will implement the repository structures into a relational database. If models are created with Rational Software Modeler, a version-control system (such as Rational ClearCase) can be used to manage the model files. You can even use an open source tool such as CVS to manage the files that a variety of modeling tools can generate. The key is to have some form of version control and access management to the architecture structure.
Organizations typically conduct business modeling to better understand the processes that individuals perform to support the business goals. These processes may be performed manually or through some form of software or hardware automation. The enterprise architecture supports these models in a manner similar to the other architecture areas by organizing the workflows by functional area (see Figure 2). However, for business processes, the repository folder structure may have significant differences from the other areas, because not all processes are intended for automation. For example, in the Corporate domain, the subfolder structure doesn't directly match the application Corporate domain (see Figure 3), as there are manual processes for corporate measurement, Sarbanes-Oxley (SOX) Act reporting, and the like.
Figure 2. Business process modeling structure
Note that the materials stored in the repository transcend projects: They represent a true corporate asset. Materials such as requirements, system architecture, and data structures are not restricted to a single project and are intended to be reused. Project-level materials, which are only really useful during the lifespan of the project itself, can be stored in one of a myriad of file-storage locations, such as a project wiki or shared Web site.
The application architecture organizational structures depend heavily on the organization's business functions. If the organization is following the structure recommended by the IT Infrastructure Library® (ITIL), the application architecture will look similar to Figure 3.
Figure 3. Example application folder and file structure
Additional areas may also be useful for other company support systems:
- Product management:
- Product pricing
- Quoting
- Product catalog
- Sales and order management:
- Sales force management
- Order entry
- Order fulfillment
- Workforce management
Under these main and secondary levels, applications can be organized according to their primary function, such as an application that performs order entry under the Sales and order management > Order entry domain. Systems that have multiple functional areas, such as a system that handles order entry, inventory management, and provisioning, can be broken into logical subsystems that can be stored with the appropriate functional area. Similarly, if an organization has multiple overlapping applications, these can be grouped under a common application name to underscore the need for merging functional behavior.
Under each application folder, a common file-management structure is useful, as shown in Figure 4. In particular, this approach advocates using viewpoints, a model organizational structure that the IEEE 1471 standard advocates. This approach serves two purposes: First, it provides for breaking the model into separate areas to support parallel modeling (such as use case development while logical analysis is ongoing). Second, it focuses the model or particular stakeholder's needs (for example, the operation support team and the deployment viewpoint).
Figure 4. Application architecture folder and model file structure
This same structure can be used to manage code along with models, or the application code base can be managed independently from the model and simply referenced.
The data architecture area is intended to capture the structure of persistent databases. There are two kinds of databases of interest: application dependent and application independent. Application-dependent data schemas are created to support a specific application, such as to store orders for an order-entry system. The other kind of database supports multiple applications, such as a billing engine. Figure 5 shows one way to manage model and supporting files for an application-dependent datastore. Notice that the structure under the data architecture area mimics the structure of the application area, as you would expect for application-dependent datastores. In the case of a billing engine, there would be no subpackage corresponding to an application; instead, the billing engine is on its own.
Figure 5. Data architecture folder and file structure
The same subfolder structure is under either the system-dependent or system-independent datastore: an area for the data dictionary to describe the data fields, the logical data model (which is useful for application design), and the physical data model (used to generate the database scripts in Data Definition Language or DDL).
The final area of interest to the enterprise architecture framework are the services that an enterprise service bus (ESB) provides, such as IBM WebSphere ESB.® The purpose of this architectural area is to define the enterprise services that applications provide or consume. The structure to support models and other artifacts is also based on functional areas, but now the services themselves define the low-level folder structure, as shown in Figure 6.
Figure 6. SOA folder structure
Under each service, the folder structure should include something similar to Figure 6. The application gateway (adapter) is needed to interface with the provider or consumer of a service. The implementation folder contains Web Services Description Language (WSDL) files and other implementation artifacts. The model should be organized similar to applications, with viewpoints that capture specific service design information, such as the enterprise object model for data transfer objects.
Establishing an enterprise architecture repository is a challenging task. Simply creating a usable structure that the enterprise can maintain is difficult enough, but then the repository must be maintained and expanded over time—all the while making sure that the materials are kept current, accurate, and usable. To that end, here are a few key milestones to consider.
- Discover the core business architecture: Determine the true functional structure of the organization, including how products are created, packaged, sold, and billed; how the company is organized and managed; and where and when infrastructure development (such as software) is conducted.
- Generate the repository structure: Create the initial structure and place it under source control. The structure should reflect the most stable parts of the functional business operations.
- Manage the repository: Periodically review and assess all materials in the repository for correctness, cohesiveness, consistency, and coherency. Nothing kills a library faster than going out of date.
As shown in this article, any enterprise of sufficient size will gain a tremendous value in organizing development artifacts for reuse. Any company that permits development artifacts to fall into disuse is simply wasting money. Moreover, not only is the initial effort wasted, but money and time are further wasted in rediscovering this lost information when changes are required. Is it any wonder that an organization can become utterly dependent on a cadre of individuals who hold the keys to the kingdom in their heads? Only by organizing company materials into a reusable library of assets—and by creating that library around the core business functional areas—will this situation change. Consider how you want to spend your organization's money—on rediscovery of lost materials every time a system change is required or on new customer acquisition and product development. The choice is up to you.
Learn
- Discover more information about
Rational
Software Architect,
Rational
ClearCase,
and
Rational
RequisitePro.
- Discover more about the advantages of
WebSphere ESB and other WebSphere Business Integration software.
- Learn more about the
ITIL structure and process-improvement
technique.
- Read
"Comparing
and merging UML models in IBM Rational Software Architect: Part 1, Comparing models
with local history"
to find out more about how to manage models that are placed under source control (developerWorks, July 2005).
- Browse the
technology
bookstore
for books on these and other technical topics.
- In the
Architecture
area on developerWorks,
get the resources you need to advance your skills in the architecture arena.
- Use
IBM
on demand demos
to learn about various software products and technologies from IBM.
- Stay current with
developerWorks
technical events and webcasts.
Get products and technologies
- Download a trial
version of
Rational
Software Modeler.
- Download a trial
version of
Rational
ClearCase.
- Download a trial
version of
Rational
RequisitePro.
- Download a trial
version of
Rational
Software Architect.
- Download
IBM
product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational, Tivoli®, and WebSphere®.
Discuss
- Participate
in the discussion forum.
- Check out
developerWorks
blogs
and get involved in the
developerWorks
community.
Benjamin A. Lieberman serves as principal architect for BioLogic Software Consulting. Dr. Lieberman provides expertise in consulting and training on a wide variety of software development topics, including requirements analysis, software analysis and design, configuration management, and development process improvement. Dr. Lieberman brings more than ten years of software architecture and information technology experience in various fields, including telecommunications, airline travel, e-commerce, financial services, and life sciences. His consulting services are based on the best practices of software development, with specialization in object-oriented architectures and distributed computing -- in particular, Java™-based systems and distributed Website development (J2EE), XML/XSLT, Perl, and C++ based client-server systems. Dr. Lieberman has provided architectural services to such organizations as EchoStar, Jones Cyber Solutions, Blueprint Technologies, Trip Network Inc., Galileo International, Duke University, and the University of Colorado. He is also an accomplished professional writer with a book and numerous software-related articles to his credit. Dr. Lieberman holds a doctorate in biophysics and genetics from the University of Colorado, Health Sciences Center, Denver, Colorado. You can contact Dr. Lieberman at blieberman@biologicsoftwareconsulting.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
