Phase 1 : Introduction And overview

Question 0

What definition does Lankhorst provide for EA?

Answer 0

EA: a coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure.

Question 1

How is the term Architecture defined by the IEEE 1471-200 standard ?

Answer 1

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principle guiding its design and evolution.

Question 2

Explain why the architecture integration process in complex integration cases that involve multiple stakeholders, is a bottom-up process. Make use of an example in your explanation.

Answer 2

In complex integration cases that involve multiple stakeholders, it is clear that integration is a bottom-up process, in the sense that first concepts and languages of individual architectural domains are defined, and only then is the integration of the domains addressed.

Eg. In cases where the architectures are developed by different stakeholders those architectures are given and used in practice, and cannot be changed. It is up to those who integrate these architectures to deal with the distinct nature of architectural domains.

Question 3

Discuss the role of compositionality in dealing with the complexity of architectures. make use of an example.

Answer 3

Many different architectures or architectural views co-exist within an organization. These architectures need to be understood by different stakeholders, each at their own level. The connections and dependencies that exist among these different views make life even more difficult. Management and control of these connected architectures is extremely complex. Primarily, we want to create insight for all those that have to deal with architectures.

The standard approach to dealing with the complexity of systems is to use a compositional approach, which distinguishes between parts of a system, and the relations between these parts. Eg (any eg that indicates parts and wholes is accepted) To understand how a car functions we first describe the parts of the car such as the engine, the wheels, the air conditioning system, and then we describe the relationship among these parts. Likewise we understand the information system of a company as a set of systems and their relations, and we understand a company as a set of business processes and their relations.

Compositionality also plays a central role in the architectural approach. Eg the IEEE 1471 standard defines architecture as the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment (together with the principles guiding its design and evolution)

Question 4

What is the purpose of using models to represent enterprise architectures ?

Answer 4

Models provide the means to create precise definitions and constraints about the various architectures in order to create insight into the complexity of the enterprise architecture and to avoid conflicts and inconsistencies between the different domains.

Question 5

Provide a concise definition of the domain concept?

Answer 5

Any subset of a conception (being a set of elements) of the universe that is conceived of as being some ‘part’ or ‘aspect’ of the universe.

Question 6

Provide a concise definition of the term Model.

Answer 6

A purposely abstracted and unambiguous conception of a domain.

Question 7

Provide a concise definition of the term Modelling.

Answer 7

The act of purposely abstracting a model from (what is conceived to be) a part of the universe.

Question 8

Provide a concise definition of the view concepts

Answer 8

A representation of a system from the perspective of a related set of concerns

Question 9

Provide a concise definition of the viewpoint concept

Answer 9

A specification of the conventions for constructing and using a view; a pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.

Question 10

What is the essential difference between a symbolic model and a semantic model ?

Answer 10

A symbolic model expresses properties of architectures of systems by means of symbols that refer to reality. Whilst a semantic model is an interpretation of s symbolic model, expressing the meaning of the symbols in that model,

Question 11

Discuss the relation between the 4 Modelling concepts of Architecture, Enterprise, Symbolic Models and Semantic Models. Make use of a concept map in your discussion.

Answer 11

See pg 62 for the diagram .

An enterprise is described or represented by an architecture.

An architecture may be expressed by multiple symbolic models, and one symbolic model may in turn be interpreted by several semantic models.

The distinction between symbolic and semantic models is the distinction between using symbols to refer to reality,and abstractions of reality that only refer to reality by interpreting the symbols of the symbolic model

Question 12

Describe the architecture process in terms of the architecture description life cycle.

Answer 12

See fig 1.2 in textbook

The architecture process consists of the usual steps that take an initial idea through design and implementation phases to an operational system, and finally changing or replacing this system, closing the loop. In all of the phases of the architecture process, clear communication with and between stakeholders is indispensable. The architecture descriptions undergo a life cycle that corresponds to his design process. The different architecture products in this life cycle are discussed with stakeholders, approved, revised etc, and play a central role in establishing a common frame of reference for all those involved.

Question 13

Briefly discuss Business-IT alignment as an internal enterprise architecture driver, make specific reference to the work of Henderson and Venkatraman’s Strategic Alignment Model

Answer 13

Business-IT alignment is commonly recognized as an important instrument to realize organizational effectiveness. Such effectiveness is not obtained by local optimizations but is realized by well-orchestrated interaction of organizational components. Effectiveness is driven by the relationships between components rather than by the detailed specification of each individual component.

The well-known strategic alignment model of Henderson and Venkatraman distinguishes between the aspects of business strategy and organizational infrastructure on the one hand, and IT strategy and IT infrastructure on he other hand. The model provides four dominant perspectives that are used to tackle the alignment between these aspects. One can take the business strategy of an enterprise as the starting point, and derive its IT infrastructure either via an IT strategy or through the organizational infrastructure; conversely, one can focus on IT as an enabler and start from the IT strategy, deriving the organizational infrastructure via a business strategy or based on the IT infrastructure. In any of these perspectives, an enterprise architecture can be a valuable help in executing the business or IT strategy.

Question 14

Briefly discuss the positioning of EA in the management of the enterprise.

Answer 14

See fig 1.4

In fig 1.4 EA is positioned within the context of managing the enterprise. At the top of this pyramid, we see the mission of the enterprise: why does it exist? The vision states its ‘image of the future’ and the values the enterprise holds. Next there is its strategy, which states the route the enterprise will take in achieving this mission and vision. This is translated into concrete goals that give direction and provide the milestones in executing the strategy. Translating those goals into concrete changes to the daily operations of the company is where EA comes into play. It offers a holistic perspective of the current and future operations, and on the actions that should be taken to achieve the company’s goals. Next to its architecture, which could be viewed as the ‘hard’ part of the company, the ‘soft’ part, it’s cultures formed by its people and leadership, and is of equal if not higher importance in achieving these goals. Finally, of course, we see the enterprise’s daily operations, which are governed by the pyramid of fig 1.4

Question 15

Discuss the relationship between stakeholders and architects in terms of an approach to bridge the EA communication gap.

Answer 15

Architectures or blueprints provide a “picture” of the enterprise to whoever has a need to be informed about the business the architects are responsible for creating these pictures in the form of models. The recipients of or client of the architect are called stakeholders and is defined as: an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. Generally speaking a stakeholder sees a part of the architecture called a viewpoint.

To create an integrated perspective (or blueprint) of an enterprise, the architect need techniques for describing architectures in a coherent way and communicating these with all relevant stakeholders. Different types of stakeholders will have their own viewpoints on the architecture. Furthermore, architectures are subject to change, and methods to analyse the effects of these changes are necessary in planning future developments.

Often an enterprise architect has to rely on existing methods and techniques from disparate domains, without being able to create the ‘big picture’ that puts these domains together. This requires an integrated set of methods and techniques for the specification, analysis, and communication of enterprise architectures that fulfils the needs of the different types of stakeholders involved. Architecture models, views, presentations, and analyses, therefore, all help to bridge the ‘communication gap’ between architects and stakeholders.

Question 16

Briefly list and discuss the 6 aspects involved in describing EA.

Answer 16

OBSERVING THE UNIVERSE - the viewer is a stakeholder of (part of) the organizational, technical, or other systems that make up the enterprise, ie. , the universe that the viewer observes. The conception of this universe then is the architecture of the enterprise. The representation of this architecture is an architecture description, which may contain models of the architecture, but also, for eg. Textual descriptions.

CONCERNS - in conceiving a part of the enterprise, stakeholders will be influenced by their particular interest in the observed enterprise, ie their concerns. Note that stakeholders, as well as their concerns, may be regarded at an aggregated as well as at individual level.

OBSERVING DOMAINS - viewers may decide to zoom in on a particular part of the universe they observe, or, to state it more precisely, they may zoom in on a particular part of their conception of the universe, in our case the enterprise.

VIEWS AND VIEWPOINTS - stakeholders therefore require specific views of an architecture that focus on their concerns and leave out unnecessary information. Since we put models central in our description of architectures, this implies that we have to provide different views of these models to accommodate the stakeholders needs. A view is specified by means of a viewpoint, which prescribes how views that address particular concerns of he stakeholders are constructed, given the architecture under consideration.

WAYS OF WORKING - creating and using architecture models typically involves several related ‘ways of working’ :
**a way of thinking : articulates the assumptions about the kinds of problem domains, solutions, and modellers involved.
**a way of Modelling : identifies the core concepts of the language that may be used to denote, analyse, visualize, and/or animate architecture descriptions
**a way of communicating : describes how the abstract concepts from the way of Modelling are communicated to human beings eg. In terms of a textual or a graphical notation ( syntax, style, medium)
**a way of working : structures (parts of) the way in which a system is developed. It defines the possible tasks, including sub tasks, and ordering of tasks, to be performed as part of the development process. It furthermore provides guidelines and suggestions(heuristics) on how these tasks should be performed.
**a way of supporting : the support that is offered (possible automated) tools for the handling (creating, presenting, modifying, etc) of models and views. In general, a way of supporting is supplied in the form of some computerized tool.
**a way of using : identifies heuristics that :
Define situations, classes of stakeholders, and concerns for which a particular model or viewpoint is most suitable;
Provide guidance in tuning the viewpoint to specific situations, classes of stakeholders, and their concerns.

ENTERPRISE ARCHITECTURE MODELS - in an ideal situation, we would have a single model for an enterprise architecture, to ensure coherence and consistency between all its different parts. In reality, such a model will probably never exist, especially when we talk about multiple architectural domains. In practice, an architecture (and especially an EA) will arise in a bottom-up fashion. Partial models from different domains will be constructed according to the needs in those domains. Where these touch upon each other, inconsistencies may appear, which need to be resolved eventually since the real-world system being designed must of course be consistent. In this way, we slowly move towards this Platonic underlying model, and the partial models from which it is constructed can be seen as views of the total architecture.

Question 17

Discuss the need for an integrated architectural approach in an enterprise’s architecture practice; align discussion to the architecture life cycle (design, communication, realization no change).

Answer 17

Companies have long recognized the need for an integrated architectural approach, and have developed their own architecture practice. Nevertheless, they still experience a lack of support in the design, communication, realization, and management of architectures. Several needs can be categorized as follows with respect to different phases in the architecture life cycle.

Design : when designing architectures, architects should use a common, well-defined vocabulary to avoid misunderstandings and promote clear designs. Such a vocabulary must not just focus on a single architecture domain, but should allow for the integration of different types or architectures related to different domains. Next to a common language, architects should be supported in their design activities by providing methodical support, general and organization - specific guidelines, best practices, drawing standards, and other means that promote the quality of the architectures. Furthermore, to facilitate the design process, which is iterative and requires changes and updates to architectures, support for tracking architectural decisions and changes is desirable.

Communication : Architectures are shared with various stakeholders within and outside the organization eg. Management, system designers, or outsourcing partners. To facilitate the communication about architectures, it should be possible to visualize precisely the relevant aspects for a particular group of stakeholders. Especially important in this respect is to bring about s successful communication on relations among different domains described by different architectures (eg processes vs applications) , since this will often involve multiple groups of stakeholders. Clear communication is also very important in the case of outsourcing of parts of the implementation of an architecture to external organizations. The original architect is often not available to explain the meaning of a design, so the architecture should speak for itself.

Realization : to facilitate the realization of architectures and to provide feedback from this realization to the original architectures, links should be established with design activities on a more detailed level, eg, business process design, information Modelling, or software development. Companies use different concepts and tools for these activities, and relations with these should be defined. Furthermore, integration with existing design tools in these domains should be provided.

Change : an architecture often covers a large part of an organization and may be related to several other architectures. Therefore , changes to an architecture may have a profound impact. Assessing the consequence of such changes beforehand and carefully planning the evolution of architectures are therefore very important. Until now, support for this has been virtually non-exist