An example is provided in the section Evaluating Different Options with Architecture Analyses. A one- or two-page high-level model can show a top-down view of the actors, roles, and business services and functions, as well as how they are expected to be supported by new and already existing application and infrastructure services, and how they interface with other application services. On the other hand, the business users will also be able to understand how the architect is shaping the systems that they will use.ĪrchiMate, now adopted by The Open Group, is very good at bringing people together because it makes it so easy to build and understand a model. This generates discussion that allows the architect to understand the business processes. If the architect can produce a model and show it to the business users, they will immediately recognize if the business roles, services, and processes are represented accurately. Agile methodologies help in dealing with them, but it's still difficult to find a common language between IT and business. Lack of clarity and completeness in the requirements, poor understanding of the business processes, and changing requirements (which usually occurs due to one of the previous reasons) are the most common and the most expensive sources of problems. As anyone that has been involved in IT projects long enough knows, and as any statistics on project failures show, most of the problems in projects are created long before the implementation starts. Modelling the business allows the architect to get involvement from the business areas directly, and it's a very good exercise to do at the beginning of any new project, as soon as the user requirements (or use cases or user stories, depending on the methodology) are available. The ArchiMate® meta-model captures this concept quite well:įigure 1: The ArchiMate Meta-Model (Source: ) This provides a layered model of the business, containing most of the information that is required by the architect to start designing the system. These use infrastructure services and physical nodes, such as networks, servers, storage, and so on. Application services are provided to support those processes and are materialized in application components and functions. Generally speaking, in any organization, people play roles, through which they execute business processes that provide business services to someone. The first step in creating an architecture concept for a system is to model the business. Modelling the Business Architecture with the Business Users and Business Analysts It is easier to steer change when it's going to happen anyway. The steps in the following sections describe one method and some tools that can be used for IT projects and change management procedures. There are many challenges to building an optimal landscape, which is undoubtedly based on a Service Oriented Architecture (SOA). It's all about optimizing the use of resources to fulfil business needs in accordance with the priorities of the organization. In fact, EA and SA (which includes network, software, security architecture, and so on) are facets of the same business function: architecture. So obviously, EA and SA have to work together to effectively build an architectural landscape and reap its benefits to the maximum extent with minimum waste. Money is not abstract, so using it cannot be based on abstract constructions. Only then will he be able to justify his recommendations in practice and not just in theory. In other words, for the architect to have a real view of the IT landscape and the future needs of the business areas, he needs to be involved in the IT projects. The problem is not the "why" or the "what" but the "how." And "how" is exactly where SA excels. Principles of reuse, standardization, awareness of innovation, alignment between IT and business, and so on can all obviously help any organization reduce maverick and superfluous costs and instead use its costly IT department to achieve efficiency gains and boost business. The mere fact that these questions are asked indicates that very often EA is completely misunderstood and ends up as an isolated function with little contact with the organization's real problems and opportunities.īut on the other hand, it's actually not hard to understand where EA can provide value-a lot of value. It's common to find questions in forums, such as "Can you explain EA's value in one sentence?" or "What is the main obstacle for EA's success?" or even worse. Of the two, EA is sometimes regarded as the rich and decadent relative while SA is the honest, reliable, and hard-working one. Enterprise Architecture (EA) and Solution Architecture (SA) are often seen as different practices.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |