The purpose of enterprise architecture is to provide a blueprint and long-term guidance for the enterprise in terms of structure and operation for its business and IT. It can help in facilitating decision making and supports enterprise modernization efforts. It can enhance collaboration and interoperation across an enterprise and can promote enterprise efficiency and effectiveness by streamlining business process and technology implementations. It enables resource sharing and increases cost efficiencies by identifying common and sharable components and services.
1. Stakeholder participation
2. Architecture modeling
3. Architecture usage
4. Architecture maintenance and program management.
We will discuss each category in the following sections. We will address, as well, how SOA can enable effective EA practice.
3.0. Stakeholder Participation
One goal of EA is to break down stove-piped organizational structures and promote cross-functional collaboration. In order to achieve this goal, stakeholders must participate in EA development activities. However, traditional enterprise culture, backgrounds of people, organizational structure, and sense of priorities often limit stakeholder participation. The EA development process cannot progress well if the “right” people don’t participate. To encourage participation, the value proposition of enterprise architecture must be clearly defined and accepted.
First, we have to identify common services and service owners. The service owners are major stakeholders. Service consumers are stakeholders as well because they are defining service requirements. In SOA practice, the roles, responsibilities, and target picture (services) are clearly defined. Thus, it’s easier to facilitate stakeholders’ participation and to promote collaboration via common services and service infrastructure.
4.0. Architecture Modeling
One challenge for architecture modeling is to decide the depth and breadth of architectural scope, for example, how to model “the big picture”. The second challenge is how to ensure that each audience of the model receives the information they need in a form they can understand. The third challenge is to ensure that the correct level of detail is provided to those that need it, when they need it. Too often, EA modeling efforts jump too quickly into the detailed design work, losing sight of the big picture. . In current EA practice, especially in the Federal Government sector, we see an emphasis on data gathering and artifact collection, but it lacks of emphasis on the creation of meaningful models and easy to understand conceptual abstractions. Most EA practices treat EA as an engineering process, and replace architectural approaches and methodologies with EA frameworks and modeling tools. It appears people believe that just by using an EA tool and an EA framework, and follow some widely published EA process, they will get the enterprise architecture as the end products automatically. These efforts ignored the original meaning of “architecture,” which should be a conceptual creation that gives us a well-informed and structured cohesive big picture. EA should be unique for each individual enterprise.
SOA can be developed iteratively with atomic service components. It is well-defined and loosely coupled. It does not require hard-wired components to create complex pictures. This solves the problems in determining depth and breadth of architecture coverage and reduces the complexity of architecture modeling.
5.0. Architecture Usage
EA products (e.g. models, artifacts, descriptions, guidance) have to be accepted by the owning organizations before they can be put into real usage. Stakeholder participation and the value proposition of EA work are determiners of EA acceptance, as discussed above. What has also been a challenge to many organizations is to understand how to apply EA to their individual projects. People have to figure out which parts of the complex EA products are relevant to their projects and in which ways. Usually, there are gaps between EA products and the requirements for each individual project.
6.0. Architecture Maintenance and Program Management
Effective lifecycle management and IT governance policies, processes, and structures are required for effective architecture maintenance and program management. Each enterprise must define their unique requirements for lifecycle management and IT governance. These are not simple tasks, many organizations feel challenged and time consuming in getting these thorough.
Due to its iterative development nature, SOA-based architecture maintenance is built into the service lifecycle. Tools are developed rapidly around service lifecycle management and service governance. Although they are not quite matured yet, they can be served as a base for further development and customization to meet the unique needs from each individual enterprise. They are certainly very helpful in lifecycle management and governance practice.
*This paper is published in 2007 in the IASA Enterprise Architecture - A 20 Year Retrospective.