Enterprise Architecture is related to business optimization, which addresses issues such as enterprise architecture, performance management, organizational structure, and process architecture. It encompasses the description of the current and future structure and behavior of an organization's process, information systems, people, and business units to ensure that they are aligned with the organization's strategic direction. In this paper, I will describe a simplified top-down enterprise architecture in a SOA (Service-Oriented Architecture) environment, with a focus on information technology, with the goal of achieving optimal alignment between business and IT

I will describe the different focuses of the top-down approach to enterprise architecture

Objectives of Enterprise Architecture Overview of the Methodology Relationship to the BEA SOA Domain Model

You will be able to get a good idea of the current and future structure and behavior of the units to ensure that they are in line with the organization's strategy. In this paper, you will gain a good understanding of the advantages of a top-down approach to enterprise architecture driven by business strategy and the associated organizational considerations

Different Focuses of a Top-Down Approach to Enterprise Architecture

In a top-down approach, from the business to IT, it is necessary to separate the different focuses of the business and IT in the different plans, and thus lay a common ground between the two

The plans related to business are called business process plans, and the plans related to business are called business process plans. The business-related planning is called business process planning, the IT-related planning is called application planning, and the planning between the two - the most meaningful part of the approach, because it aims to provide the best possible alignment between business and IT - is called functional planning. To describe hardware, networks, operating systems, application servers, databases, and so on, you can introduce the concept of technology planning. I don't intend to describe technology planning in detail, because my main purpose is to recommend a way to achieve the best possible alignment between IT and the business through the foundation of a public ****

The diagram describes these plans and their interrelationships, and I'll go into more detail on them

Diagram The different focuses of the top-down approach to enterprise architecture

Business process planning

This planning focuses on business processes in the context of the business strategy Enterprise architecture that works closely with the different lines of business in the organization starts with the business requirements defined by the business strategy, and models the major enterprise business processes, for example, by using AquaLogic BPM Design. AquaLogic BPM Designer accomplishes this at the design level, which helps architects understand the major processes across the enterprise and advances this approach by involving more sales reps. Using AquaLogic BPM Designer, business analysts can simulate business processes and provide a measure of the optimization that occurs when processes are reverse engineered. Business process planning is owned by the business itself The main task of the architect is to capture business requirements and identify ***similar business services that can be used by different lines of business within the organization

Take the example of a banking environment, for example, where the first step is to design the processes for each banking operation (for example, loan import/export operations). The identification of ****similar services is achieved by designing processes at the organizational level. To some extent, the authorization system and the accounting system should be able to be reused in different processes, for example, in the process of issuing a letter of credit (LC) or in the process of approving a loan. Functional blocks provide business services that can be reused across business processes Business services are also ideal building blocks for SOA These services should also be able to be reused and reconfigured to provide the agility required by the business In selecting these functional blocks and the data that needs to be *** shared across them, the business line should provide enterprise architects with enough knowledge of the business so that it can be reused and understood by the entire organization. After this, the business needs to be added to the plan

This common approach should result in a common language and common taxonomy that can be used across the organization

The definitions of common entities and common domain models have common meanings across the organization and can be reused by different lines of business. This plan is like a city plan that organizes functional building blocks into zones and areas that are relevant to different lines of business within the organization

A common language will be very helpful in reusing functional building blocks and in ****ing data across these blocks. Specification models should be ****ed within the enterprise repository. Management considerations should define the way in which models are designed, accessed, validated, and modified. I'll go into more detail on these considerations later in this paper. p> Returning to the bank example, in this organization there should be one business line that handles payments, foreign currency exchange, and mortgages, another that handles loans, a third that handles import/export operations such as letters of credit (LC) and collections, and a horizontal business line that handles authorization, accounting, reporting, and risk management. If we use the analogy of a city plan, each of these lines of business can be thought of as a special zone

< p> Looking further into the import/export line of business, there are functional blocks related to LCs and collections, respectively, and the functional blocks representing LCs can be subdivided into the different services that LCs are expected to provide. The blocks are expected to provide functions (or services) such as issuance of LCs, modification of LCs, use of LCs, and reimbursement of LCs, which are the business services of the LC block that are dependent on the functionality provided by the authorization block, the accounting block, and the disbursement block.

The authorization block will grant lines of credit to customers based on their status, and the authorization block may rely on the functionality of the risk management block. The LC functionality will also use services provided by the accounting and payment blocks, and the payment block will use the functionality of both the accounting and authorization blocks.

The description of the functional plan uses business terminology, and is subdivided so that it can be mapped to applications and services within the application. In this environment of the bank example, the accounting and authorization services are reused at the organizational level

Once the functional building blocks have been identified, the communication between them needs to be defined, and this implies the development of a canonical data model that can be described using a UML model, and this leads to the XML representation of the data. In the bank example, whether used in the LC block or in the Loan block, the accounts are the same, the customers are the same, and the accounts and customers are entities defined in a cross-organizationally***tional business model that is represented by two canonical models, one for the account data and the other for the customer data. These services can be CRUD (Create Retrieve Update Delete) services or composite services The best way to define a canonical model is to refer to industry standards Banking systems use the SWIFT standards MT messages defined in the SWIFT standards manual define banking operations at the level of business use case usage messages These messages can be easily mapped into messages that can be used across the organization. These messages can be easily mapped to XML messages that can be used across the organization. Maximum compliance with standards is very helpful in extending business operations used within a single organization to B2B operations across multiple organizations.

There is more information on service design, modeling, and runtime concerns in Understanding the Service Lifecycle in SOA at Design Time and Understanding the Service Lifecycle in SOA at Runtime, by Quinton Wall.

After defining the functional blocks and data models used in a block, these assets should be reusable by different lines of business in the enterprise repository BEA AquaLogic Enterprise Repository can be used to ****enjoy the enterprise information assets

Application and implementation planning

As I mentioned, functional building blocks are the ideal choice for SOA building blocks. Choosing services identified using a top-down approach will result in a better match between business needs and IT

The implementation of services in application planning will depend on the type of service and how the service relates to the different SOA tiers, which include the representation and compositing tier, the orchestration tier, the business services tier, and the data access tier or connectivity tier

The choice of the right product to implement these blocks needs to be made with great care. The organization's environment, such as existing applications and technical constraints, should be taken into account When making implementation choices, application planning and technology planning are inseparable Ideally, BEA WebLogic Integration is a good choice for system-to-system processes BEA AquaLogic BPM is ideal for manually driven processes BEA WebLogic BPM is a good choice for designing and reengineering processes for business process planning AquaLogic BPM is ideal for manually driven processes BEA WebLogic Portal is well suited for developing and enjoying the presentation layer through WSRP throughout the organization, thus facilitating reuse of the presentation layer and portal federation AquaLogic Data Services is an ideal tool for the data access layer, while AquaLogic Service Bus is well suited for application-to-application communication. In a real-world environment, these choices depend on the assets and requirements available within the organization. In addition, the use of a reference architecture should be considered within the organization's environment.

An organization's reference architecture is one that provides best practices and blueprints for how to implement each of the building blocks based on the tiers and services to which they belong. This diagram also depicts the SOA layers required to implement the organization's functional building block services through the appropriate products The definition of the reference architecture is achieved through a process that involves the appropriate business and IT layers This model can be used to implement the building blocks for each of the SOA layers within the organization's environment

Diagram: Reference Architecture for an Organization

A reference architecture should be able to promote the use of the building blocks defined by the management team and the services to which they belong. This goal should be achieved incrementally rather than overnight through dramatic change. There should be a management team that manages the different domains - global business and strategic domains, information systems domains, and project domains - and that supports the adoption of appropriate tools to facilitate reuse across the organization.

The management team should create and maintain assets that reflect the current state of the organization, such as existing functional modules, in which there is a global description of the current state. This can be very helpful in determining the current silo of the information system.

A roadmap should also be considered in defining the target state.

Guiding principles, policies, taxonomies, enterprise specifications, data models, data repositories, best practices, reusable assets, and other guidelines that need to be defined and maintained by the management team touch all lines of business as well as IT

The enterprise architecture should be able to reconcile IT with the organization's strategy, and it should be able to easily adapt to the changing nature of the business. This requires that the business architecture and guiding principles must culminate in the functional building blocks needed to assemble and disassemble business flows

Information Systems Scope

The enterprise architecture team references existing functional building blocks, and it can also define new functional building blocks needed for business processes, as defined in the global business scope of business process planning

Information Systems Scope is related to functional planning and should be able to provide the right language in a language that can be understood by both the business and IT

The information systems scope is related to functional planning and should be able to provide the right language in a language that can be understood by the business and IT. Information system assets are defined in functional planning The definition includes communication between applications at the functional level as well as standardized enterprise data models, common languages, taxonomies, and data repositories Access to these assets should be defined and controlled

Work in functional planning should correspond to applications in application planning Standards and product support should be aligned with the work covered by each application. Standards and product support should be defined in conjunction with the aspects covered by each application

Project Scope

At the operational level, most initiatives should be realized as projects to ensure the successful application of guidelines and rules Architects from the management team should ensure that the detailed technical requirements and the project architecture are aligned with the enterprise guidelines, policies, and use of corporate languages. Applying architectural blueprints to deliverable projects early in the investment significantly increases the likelihood of on-time, on-budget, and on-quality deliverables with better reusability. Only then can the project provide new SOA building blocks that can be reused throughout the organization.

Applying a globally-driven strategy to a new project is an evolutionary approach to achieving the goal, and the process is smooth rather than explosive. Repository Management

Access to the regular model definitions of the enterprise should be globally available in order to develop a common enterprise language that uses a common taxonomy. Without a common language, reuse cannot be achieved. Effective management of information system assets can be achieved through the use of an enterprise repository, which should be accessible throughout the organization and managed by the management team, and which should provide an extended view of assets and metadata. The AquaLogic Enterprise Repository is an excellent tool that can be used to support enterprise architecture

Methodology Overview

An excellent way to design an enterprise architecture is to describe the current state of each of the above plans, as shown in the figure. This will help to assess the gaps between the business and IT, and to identify silos, and then define a roadmap to get there. The methodology actually analyzes the different plans described at the beginning of this paper to assess the current state and define the target state

Figure Overview of the methodology

Current state (existing)

The assessment of the current state can be done in a top-down manner, bottom-up manner, or a mix of the two, and the definition of the current state can be done for each plan

Starting from the business processes, generic work should be done to define a roadmap to achieve the goals. Generic work should be done by both the line of business and IT*** to define the current state of the business process Modeling these processes with AquaLogic BPM Designer provides architects and business representatives with a*** common ground Enhanced graphs can be drawn using AquaLogic BPM bit by bit business processes and simulation possibilities

Starting with the existing applications Start with the existing application and work with IT to identify existing functional blocks so that duplicated functionality is possible and silos can be identified

Once a siloed application has been identified, a method for eliminating the silo through service disclosure should be defined at the target state

Target state (as it should be)

Defining the target state should be done in a top-down manner, which is the recommended approach because it builds on the business requirements and provides reusability. This is the recommended approach because it builds on business requirements and provides reusable business building blocks

Starting with the business process Working with the line of business, the optimized future state process can be modeled using the AquaLogic BMP Designer, and then moving down to identifying the functional blocks that provide the services required to composite and decompose the business process Remember that in functional planning, only a combination of the business and IT can accomplish the ****same task

After that, define the roadmap

The target state (as it should be) is defined as the business requirements.

After that, define the roadmap to achieve the intermediate goal of recognizing the state. This roadmap should be taken into account when defining the common language, specification model, and data repository. The intermediate validation steps should involve both the business and IT.

The reference architecture is planned at some point in the roadmap. Of course, the planning of the reference architecture can be done at any time, but you shouldn't wait until all the enterprise assets are defined. Effective assets should be continuously adapted to new business needs (new functional blocks will involve new implementations) The goal is to give instructions on how to do this, based on the currently available enterprise reusable assets and the technologies that should be adopted As mentioned earlier, reference architectures are in a constant state of evolution and provide the best way to implement new projects in an organization's environment with the goal of increasing reusability at some point

The reference architecture should be planned at some stage of the roadmap, of course. The management team is the primary team involved in the roadmap because it can be involved globally throughout the new project with the assets it generates and focus on delivering the agility required by the business. The management team should consist of a group of enterprise architects with different professional backgrounds, so that they can focus on one of the plans to varying degrees and lead the management. The team should have both technical and business-focused architects The management team can be a mix of senior architects from different lines of business and senior architects from IT This gives the team the necessary credentials to lead across the board

The management team's tasks can be difficult to accomplish in some environments, so strong assistance should be provided The management team's role is more or less like that of an alchemist, a person who is dedicated to getting the right things right. The role of the management team is somewhat like that of an alchemist, working to find the right recipe to catalyze the right transformation. In this regard, there are a number of articles available, such as Planning for SOA Success by David Groves and Steve Bennett Building your SOA roadmap, and Planning for SOA Success for Long-Term SOA Planning, please note that it is important to think about change management prior to applying the roadmap.

With the BEA SOA domain model, the management team has the task of leading the transformation. Relationship to the BEA SOA Domain Model

The approach described here starts with business policies and processes, and builds applications through functional building blocks, all of which can be implemented in common enterprise language and reference architectures that provide blueprints for new projects and applications. In Functional Planning, I describe the aspects of the organization that need to be addressed in order to maintain a structured view and to successfully expose assets that can be used throughout the enterprise.

In an environment where SOA is used as an enterprise architecture, senior SOA architects need to avoid common and costly pitfalls. These architects should work with the organization's management team to provide the skills needed and help the management team build a successful SOA. Taking a global approach provides management and direction for the project, which in turn provides greater consistency and a better return on investment for SOA. It reduces the maintenance costs of production applications and enhances their reusability

BEA provides a domain model that can be used to deal with the enterprise architecture. This model encompasses the previously described planning (and more) through six dimensions, and provides a pathway to a successful implementation of SOA, as illustrated in this figure

Figure 1 shows how to achieve a successful implementation of SOA.

Figure BEA Domain Model

The BEA SOA approach is a pragmatic approach to enterprise architecture that touches on all aspects of information technology. BEA provides services and training in all six areas, and is organized to enable you to implement SOA to meet your organization's own needs.

To get started, it is useful to refer to BEA SOA. Readiness Asses *** ent Report It helps you define your current state and is a good starting point for introducing SOA into your organization by taking a survey at the SOA Resource Center to receive a SOA assessment report

Conclusion

This article demonstrates the top-down enterprise architecture that is required to gain global reusability across the organization. It describes the management concerns needed to gain global reusability across the organization and highlights the need for an organization's reference architecture and defines an enterprise repository to facilitate this global approach

Original source l

? Gabriel Bechara Gabriel Bechara has been working for BEA Consulting Services for more than two years. Gabriel helps customers use BEA products such as WebLogic Server Portal and Integration. Gabriel's interests include defining approaches to software architecture, working with products in development teams, and providing the tools to bring applications to market. Gabriel's interests include ways to define software architectures, use the products in development teams, and providing the easiest way to bring applications to production. Gabriel has been in the software industry for more than a year. Gabriel lives in Chinatown, Paris with his wife and two children. lishixinzhi/Article/program/Java /ky/201311/28398