Abstract
Current enterprise architecture frameworks are inherently committed to the process paradigm by separating the data and application architectures. The N-tier architectural style is a good match to those methods, since it is based on the same separation principle. However, the process paradigm does not satisfy the information hiding and low semantic gap principles heralded by the object-oriented paradigm. This chapter presents an enterprise architecture framework that emphasizes the motivations (stemming from the business), the ends (expectations, what the business needs to achieve), and the means (what is needed to accomplish the ends), as the basis for a method to develop architectures better prepared for changes, either due to maintenance, adaptation, or enterprise integration and interoperability. The main tenets are to refine the ends into goals and objectives, increasing the level of concreteness as much as possible before delving into the design, and to adopt the service paradigm, for which a tierless architectural style is a more suitable match.
TopIntroduction
Thanks to computers and computer networks, the informational diameter of the world is getting smaller and smaller. It is increasingly easier for users to access information anywhere (powered by search engines such as Google) and to be interconnected to anyone on the planet, with social networking on the rise (according to the statistics presented in the media resources of Facebook’s site, Facebook has surpassed the mark of 900 million active users in March 2012).
Enterprises are also more and more interconnected and interdependent. Success on the market implies agility and optimization of business processes, which in turn implies concentrating on core business activities and outsourcing the rest. Virtualization, down from physical devices up to whole enterprises, has been the key for dynamic adaptation that is the basis for competitiveness. Cloud computing (Shroff, 2010) is one of the latest manifestations of the ease with which enterprises can coexist and interlink with others in the same informational space.
All this connectivity is both a bonus and a curse, leading to what could be called interaction sprawl. If the cost of interconnecting enterprises lowers, it will be increasingly done, raising problems on the interoperability, integration and alignment sides of the issue.
SOA (Earl, 2007) has been heralded as a solution to conceive and structure enterprises in a distributed world, but in practice it has been used as an enterprise integration layer to interconnect basically centralized information systems, based on an N-tier architectural style and orchestration (processes). It is not a native solution to the enterprise integration problem. The enterprise architectures should be conceived as distributed systems themselves, right from their inception. If the Enterprise 2.0 wants to seamlessly blend and be integrated in the overall distributed enterprise fabric, with an architecture geared for the constant changes and adaptations that will inevitably occur, it must adopt the same underlying distribution and decoupling principles.
This chapter concentrates on two problems that, in our opinion, have significantly contributed to hamper the changeability and adaptability of many enterprise architectures:
- •
The mismatch between the essence of a business model and the organization and structuring paradigm used to describe it. What we usually call the business is in fact a choreography performed by a set of interacting entities, which exchange values (information, money, products, service transactions, and so on). This is valid both in the external context (environment) of an enterprise (customers, suppliers, competitors, regulators, and so on) and in its internal context (stakeholders, governance board, departments, units, applications, and so on). This is an actor oriented universe, for which the service paradigm (Earl, 2007) is a close match, but usually enterprise architectures have the process as the main paradigm to describe the business. For example, Winter and Fischer (2007) structure an enterprise architecture in five layers: business, process, integration, software and infrastructure. The proposal is to perform a paradigm shift, from processes to services and from architecture layers to a society of interacting, self-contained actors that implement services;
- •
In the method used to develop the architecture, adopting a specific organization and design without sufficiently detailing the business motivations and requirements, such as defining processes directly from generic goals (Markov and Kowalkiewicz, 2008). This gives little support for transitioning from the business layer to lower, more concrete architectural layers, places a burden on analysts and turns changes and adaptations of an enterprise architecture into a harder task. The proposal is to refine goals into objectives and subobjectives, staying on the declarative side as much as possible before delving into the prescriptive side of design.
TopBackground
Modeling before designing has always been an important tenet. Since the early days of the Zachman framework (Sowa & Zachman, 1992), we understand that enterprise architecture and its underlying principles (Greefhorst & Proper, 2011; Winter & Aier, 2011) are the cornerstones of enterprises themselves.
Key Terms in this Chapter
Resource: An entity of any nature (material, virtual, conceptual, noun, action, and so on) that embodies a meaningful, complete and discrete concept, which makes sense by itself and can be distinguished from, although interact with, other entities.
Service: A set of related functionalities that define a meaningful concept in a resource interaction context.
Process: A graph of all interactions that are allowed to occur in a set of services, starting with an external request and ending with a service which neither reacts back nor initiates new service interactions.
Goal: Description, usually in a qualitative and fuzzy way, of a desired state or set of properties to achieve.
Objective: Description, usually in a concrete way, of a desired state or set of properties to achieve. This description must be concrete enough to be considered SMART (Specific, Measureable, Achievable, Realistic, and Time framed).
Enterprise Architecture Framework: Set of guidelines, best pratices and tools to analyse, classify, structure and describe the architecture of an enterprise.
Objective Graph: Decomposition of an overall objective into smaller objectives that must be satisfied, in OR or AND dependencies, to meet the satisfaction of the overall objective.
Enterprise Architecture Method: Set of steps to be taken to derive an enterprise architecture from an initial problem statement or from an already existing enterprise. This is usually used in conjunction with an enterprise architecture framework.
Conformance: Property between service A and another B ( A conforms to B ) that indicates that A implements all the features of B required to allow it to replace B in its role in some enterprise architecture.