Implementing Enterprise Architecture - An Introduction

-

IT is not only a means to conduct business, but is rapidly evolving into a business. IT performance will directly affect the profitability of the company. However, many companies do not have timely or adequately involved IT organizations in the business planning and decision-making process, and are not given in planning and IT issues such as security, scalability, and integration issues considered in the IT decision-making process are sufficiently valued.

Complexity drives change

There are many drawbacks in the traditional application integration methods. It is difficult to solve the whole enterprise integration problem by merely transferring data in two databases or calling interfaces between them. Whether in theory or in practice, such an integrated approach is meant to mean the failure of the project.

Simply thinking about the integrated system from a technical point of view can only be said to be a means of technology realization. However, to really exert the value of IT, the technical personnel must be upgraded from the technical architecture perspective to the perspective of the business architecture. From the perspective of enterprise architecture planning, IT and architecture should be considered. Convergence not only solves the integration problem, but also can fundamentally improve the value brought by IT.

Enterprise architecture is the bridge between undertaking enterprise business strategic planning and information construction, and is the core of enterprise informationization. Of the enterprise architecture, 97% are businesses and 3% are IT technologies. What are the parts of the enterprise architecture? What are the enterprise architecture methods? Which enterprise architecture method should we choose? How to do it after choosing?

Below, I briefly explain the steps in the implementation of the enterprise architecture.

Enterprise Architecture Concepts and Knowledge Tools Import

If the IT system can not meet the business needs, it will be a huge waste, and the business process does not have the corresponding IT support, and the efficiency is hard to increase. The goal of enterprise architecture is to obtain maximum business value through IT investment. It is a high-level enterprise vision that focuses on the organization's IT architecture and business architecture. First of all, we give our customers a three-day TOGAF training of the enterprise structure, quickly and accurately introduce the enterprise architecture concept and knowledge tools, so that all members of the architecture work group have a unified understanding of the enterprise architecture and ensure that the preparatory work before the implementation of the architecture work is effective.

Who needs to include the architecture working group? The composition of different enterprise architecture working groups may not be the same:

Different implementation scopes of the architecture will also cause different members of the working group. For example, the EA design will only be used for workshop management. The involved members are different from the EA design of the entire company.

Analysis of the current situation of the architecture

Many companies do not have a unified enterprise architecture. Even if they do, they have various architectures that exist independently and cannot achieve unified planning. In addition, each sub-sector’s own informatization work has caused enterprises to apply silos, resulting in poor integration and unable to have Efficient informatization, and IT's inability to keep up with the pace of change, and IT cannot align with many IT and business issues.

If you often deal with software systems, you may find that there are actually several important gaps (GAPs) in the software development process.

  1. Inconsistent business architecture to technical architecture
    1. The business architecture is made up of people, and the technical architect is assigned to another person. As a result, when the business architecture is implemented, it lacks the consideration of the technical architecture. The technical architecture lacks the awareness of serving the business and ultimately does not serve the business. Getting the final business architecture and technology architecture is not a good combination, resulting in many adaptations or repeated work.
    2. Another situation is that after the business architecture is completed, it is thrown into the technical architecture to implement it. However, the business architecture does not provide comprehensive information and cannot provide input for the technical architecture, resulting in extremely low communication efficiency.
  2. Inconsistent business architecture to business needs
    1. Although some companies have clear positions, the method is not clear. Business architecture is a set of methods. Needs analysis is a set of methods, and even there is no method. It is relying on individual capabilities. As a result, the architecture and demand deliverables are independent, and the business architecture cannot be smoothly transferred to the requirements phase.
    2. Sometimes when a person is responsible for the business of the product, the architecture and the needs are done together, there is no method guidance at this time. In fact, it is easy to get lost in the business details. Premature entry into business details is a hazard to the product, because entering the details when the product architecture is not yet clear will only waste time and lead to a shift in focus.
  3. Inconsistent business architecture and implementation
    When developing a product, development asks, “What is the value of doing this to the system?” The result found that the demand can't be traced back to the value of the system at all. Sometimes even the demanders do not know why this function was done. If the product has a long life cycle, several replacements have been made to make this product. Therefore, it is not only that the requirements document cannot be traced back, but also that it cannot be explained clearly by speaking.
    1. The business architecture adopts the business language, and the technology adopts the technical language. The two are not the same language. It is difficult to make a smooth transition. It needs to be translated again. Sometimes the business architecture is not even looked at in the implementation stage.
    2. Few developers know the business structure of the product. How can a good product be made?
In fact, business architecture and business requirements do not conflict with each other. They are just things that are at different levels. The architecture focuses on things that are more comprehensive, summarized, and organized. The requirements focus on the details of the business that the user cares about. The business requirements are the further analysis of the business architecture. However, many companies do not know how to distinguish between these when they plan their enterprise architecture, causing business people to complain.

From the above it is possible to read books. The hidden problems in product development in reality are still quite numerous and very serious. I have also experienced it. To solve these problems, we must do the following:
  • Finding a Method and Framework to Guide the Top-Level Architecture
  • Structured architecture deliverables can transfer architecture knowledge to the implementation phase of architecture migration
  • A business development platform to integrate business architecture, technology architecture, and development framework
This is also the meaning of the enterprise architecture. In order to solve the problem of IT and business consistency, the introduction and landing of enterprise architecture requires three aspects: the methodology for guiding enterprise architecture work, the architecture language for enterprise architecture description, and the smooth transition from enterprise architecture to application development.

Enterprise Architecture Framework and Method

There are many different types of enterprise architecture framework methods, because TOGAF has strong commonality, and it has been developing well in recent years. The application is also increasingly widespread, and its integrity and practicality are relatively high. Therefore, we use TOGAF in the consultation for the customer's architecture. planning.

TOGAF has an ADM architecture development method. It is a reliable and effective method and is the key to TOGAF.

TOGAF also provides a detailed architectural artifact model that includes deliverables, deliverable artifacts, and architectural building blocks that can give us more guidance.

Although TOGAF9 already provides a content framework, the framework itself does not tell you much about how to do specific architectural details. Most of the time, we have to borrow some existing models or methods, such as PCF, SCOR, CBM, and so on.

Enterprise Architecture Language

Enterprise architecture is a top-level design, so we can't describe it in the development phase of UML and other languages. We can't simply use Viso to drag and drop some legends. In consulting, we introduce the enterprise architecture language ArchiMate into the enterprise. Of course, each enterprise can also Based on this, expand your own model.

(Created with Visual Paradigm, the best ArchiMate software)

Business Development Platform

This only makes recommendations in the consultation process, and more needs to be done in conjunction with the development capabilities of the company.

Process Delivery Samples and Brief Descriptions

Enterprise architecture is suitable for large enterprises. It is also a trial to SMEs. The key point is not the size of the organization, but whether you need to use IT to help you build the company's future capabilities.

Businesses based on different scales are naturally different in complexity, so the consultation process is also different, but some methods and steps are still the same. Let's briefly look at some of the process deliverables and brief descriptions so that we can There is a preliminary understanding of the promoters of enterprise architecture.

In the preparatory stage of the enterprise architecture, one of the cores is to determine the scope of the enterprise:
  1. ...determine the principles of each architecture
  2. Vision stage needs to determine the company's core competence
  3. And carry out hotspot analysis on core capabilities
  4. And improve analysis
  5. Also need to determine performance metrics
  6. When designing processes at the business architecture stage, it is very important to establish a unified process hierarchy and process classification.
  7. In the business architecture stage, the core is to do high-level process analysis
  8. After business process analysis, analyze and form business components again
  9. Analyze the gap between the to-be architecture and the as-is architecture and form a gap analysis of business components
  10. The information system architecture mainly does entity model and application component design
  11. Technical architecture in addition to deployment design
  12. There are also technical architecture selections.
  13. In addition to the other important thing is the need for core technologies
  14. After the architecture is complete, begin to enter project portfolio management
  15. At this point, an architecture that fully supports the business is only beginning to take shape.

Do not exaggerate the importance of IT

IT informatization is to help companies operate, and operations are implemented in a strategy. From this sequential perspective, it is that IT is after the strategic planning, and this is done by two teams that have no skill requirements. We can't overestimate IT. They are not omnipotent. I'm not saying that software companies don't have this capability. They only specialize in the industry. Enterprises can't directly convert a management problem into an IT problem. To solve, the solution that is otherwise obtained must also be an IT solution rather than a solution to management. I think management problems are still better solved through management methods. The company has to do consulting for business strategy consulting. It has to plan its own thinking business. IT is more of a tool for strategic execution than these. It is impossible to put the cart before the horse and the output of IT work will not be a strategy, otherwise it will be easy to leak out. Strategic management must be completed by a team of experienced corporate strategy experts. The completion of the IT system must also require a professional team to complete. Software developers can not help you do these things. You need to be able to make overall plans for enterprise IT information. people.

References:

Comments

Post a Comment

Popular posts from this blog

History of Enterprise Architecture

-
To learn any theory, I think the best way to get started is to explore its historical roots and development process, so as to clarify the true reasons for the theory, and to prevent readers from falling into the obscure vortex shared by various theories at first. Ultimately, even why the school is not clear. The same goes for learning about enterprise architecture and enterprise architecture framework theory. Enterprise architecture is a set of theories developed since the 1970s and 1980s. Many different theoretical frameworks for enterprise architecture have been derived during the development of these decades, and many large international companies and governments have In the process of repeated exploration, an enterprise architecture that meets their respective characteristics has been created, and the methodology on how to establish an enterprise architecture, the enterprise architecture framework, and the corresponding enterprise architecture tools have also been widely used in t...
Read more

Enterprise Architecture - Organizational Roles and Skills

-
Image
Scrum development will have three roles: PO, Scrum Master, and Development Team. What are the roles of the development enterprise architecture? What skills are required for each role to be able to take on the work of the architecture? This article describes the role and skill requirements in architecture development so that everyone knows who will do it when implementing TOGAF and what skills need to be improved or improved. Software development management is more complicated, and the development and management of the architecture is more complicated. Since there is no specific practice yet, for the time being there is no in-depth understanding and refinement of these contents. The following describes most of the framework capabilities framework from TOGAF . Emerging corporate architect role The role of the enterprise architect is described in TOGAF or Non-TOGAF: Extending Enterprise Architecture over RUP . Enterprise architects are thought leaders, visionaries, and industry ...
Read more

Enterprise Architecture Design Methodology - TOGAF

-
Image
The ADM method is composed of a set of stages arranged in a ring according to the architecture development order of the architecture field. Through these development stages, the designer can confirm whether or not the complex business requirements have been fully discussed. One of the most famous ADM infrastructure diagrams in TOGAF is as follows: The ADM method is applied iteratively throughout the architecture development process, between phases, and within each phase. In the entire life cycle of ADM, each phase needs to confirm the design results based on the original business requirements. This also includes some unique stages in the business process. Confirmation work requires review of the company's coverage, time frame, level of detail, plan, and milestones. Each stage should take into account the reuse of architectural assets (formerly ADM iterations, other frameworks, system models, industry models, etc.). Photo source: TOGAF management tool from Visual Paradig...
Read more