Bringing IT Architecture to life Real world application
of a functionoriented approach
Daniël Jumelet BRINGING IT ARCHITECTURE TO LIFE
Colofon ©2018 Daniël Jumelet
ISBN 9789492190895
Translation: Carole Wilbraham Book production: LINE UP boek en media, Groningen Book design and typesetting: Riëtte van Zwol and Bas Ekkers
Photo credits: Pexels p. 2, 8, 12, 26, 66, 120, 140, 194, 202, 210, 234; Shutterstock p. 30, 48, 52, 74, 106, 128, 146, 174, 226; Jeroen Jumelet p. 50, 51, 240; Zolore p. 166
Brand names mentioned in this book: DYA®: Sogeti Nederland B.V. ArchiMate®: X/Open Company Limited trading as The Open Group DEMO®: Sapio B.V.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
TOGAF™: X/Open Company Limited trading as The Open Group
system or transmitted in any form or by any means, electronic, mechanical, photocopying,
AgilePM®: Dynamic Systems Development Method Limited
recording or otherwise, without the publisher’s prior consent.
CONTENTS Preface
9
Chapter 3 The making of function models: the heart of architecture
53
Chapter 1 Introduction
13
3.1 Patterns
54
1.1
14
3.2
A lexicon for infrastructure functions
57
3.3
ArchiMate: a semantic for the modeler
60
3.4
Application of the OIAm model approach outside of
1.2 1.3
Major tasks of an IT architect The insights and skills of the IT architect: how to read this book
15
The main messages of this book
20
the infrastructure domain
64
27
Handling data center transitions
67
Chapter 4 Working with models: examples
75
Personal practical stories Chapter 2 The role of architecture in the development process
31
4.1
Example 1: The Exchange migration
76
2.1
Phases of the design: the development sequences
33
4.2
Example 2: Identity Management for cloud solutions
88
2.2
In detail: steps in the architecture continuum
40
2.3
Involvement of stakeholders
46
The role of the community
Design of workplace services
99
49
ďťż
|5
Chapter 5 Ingredients of architecture products
107
Chapter 7 Embedding architecture
147
5.1
User stories
108
7.1 Goals
149
5.2
Service descriptions
109
7.2 Processes
150
5.3
Quality aspects
109
7.3 Roles
152
5.4 Environments
111
7.4
Architecture products
154
5.5
112
7.5
Strategic partners
155
5.6 Principles
112
7.6 Governance
162
5.7
Architecture Building Blocks
114
7.7
163
5.8
Artist’s impressions
115
5.9
Solution Building Blocks
115
User categories
5.10 Threat analyses
116
Working on Architecture repositories
121
Office politics: decision support
167
Chapter 8 Infrastructure architecture and IT security
175
8.1
Strategy determination
177
Threats and risk analysis
180
Chapter 6 Architectural products
129
8.2
6.1
Organization Context Analysis (OCA)
131
8.3 Mitigation
184
6.2
Business-IT plan, roadmap and project calendar
132
8.4
Example of a threat analysis
186
6.3
Architecture repository
133
8.5
Security Management
192
6.4
Business case / impact analysis / feasibility study
135
8.6
Privacy protection
192
Start Architecture (SSA) and Solution Foundation
136
Coping with trends
Root cause analysis
138
6.5 6.6
Project Start Architecture (PSA), Sourcing
Functional tenders
6|
Making architecture visible
BRINGING IT ARCHITECTURE TO LIFE
141
195
Appendix A Introduction to OIAm
203
A.1 What is OIAm?
204
A.2 The focus of OIAm
204
A.3 What does OIAm offer?
206
A.4 History of OIAm
207
A.5 What remains outside the scope for OIAm?
207
Appendix B Modeling protocols for the application of ArchiMate
211
B.1 The use of ArchiMate
212
B.2 Preferred concepts in infrastructure
212
B.3 Relationship conventions
217
B.4 Relationships between views and layers
221
B.5 Level of detailing
223
B.6 Agreements about naming
224
Appendix C Cloud Service Packages
227
C.1 Application Hosting
228
C.2 Web Hosting
231
C.3 Calculation
232
C.4 Data Management
233
Glossary
235
References
237
Acknowledgements
239
ďťż
|7
12 |
BRINGING IT ARCHITECTURE TO LIFE
CHAPTER 1
INTRODUCTION
This book is about how to apply architecture within the IT department of an organization. It gives the answers to questions such as: What are the tasks of an IT architect? What methods and tools are available to an IT architect in carrying out his or her work? What products are delivered as a consequence of the architect’s role? How is the architecture role embedded in an organization and how does an architect collaborate with other roles? In short, what does it mean to be a fully functioning IT architect?
The term “IT architecture” is used consistently to distinguish it from other forms, such as structural architecture or civil architecture. The term includes all forms and domains of IT architecture. If a spe cific domain is meant, this is stated explicitly. Much of what is being reviewed in this book is also useful with regard to IT-related architecture (such as enterprise architecture and information architec ture). This is important because there is a reciprocal interaction between process organization and information provisioning on one hand and the design of the IT on the other. For the sake of clarity, the design of IT is the chosen perspective in this book.
The idea behind this book comes from the development of the Open Infrastructure Architecture method (OIAm). OIAm focuses on the design of infrastructure landscapes and facilities from the perspective of functionality and quality. This is done by means of function models, for which OIAm provides a host of tools, such as generic function Chapter 1 introduction
| 13
patterns, function definitions and a design workflow. Over time, many “good practices” have been developed and elaborated. Both the OIAm design method and the processes around it are also applicable and useful to architects in other domains (apart from infrastructure architects). With OIAm as the starting point, this book gives guidelines for the pragmatic and, at the same time, methodical practice of the IT architecture role. The book is intended for anyone who wants to understand and/or wants to move forward in the IT architecture field. Primarily, this is everyone who is already working as an IT architect and is involved in designing and developing business processes or application and infrastructure landscapes. Experience within IT and knowledge of IT architecture methods such as DYA, TOGAF, DEMO, Novius and especially ArchiMate will help, because this book focuses on how to strengthen your performance in the role. But even those people who are still at the beginning of an IT architect’s career will also be able to benefit, at least with regard to the vision of IT architecture that is presented in this book. The book also includes useful elements for other disciplines by giving a “behind the scenes” look at the activities of an IT architect. The role of the architect in the creation and further development of IT is made clearer and it becomes more obvious how they support decision-making. So, for project managers, business analysts, information managers, requirements managers, 14 |
BRINGING IT ARCHITECTURE TO LIFE
service managers, buyers, IT security professionals, IT developers, technical specialists and administrators, this book contains interesting elements, at least on the subject of working together and the benefits this brings. The reading guide indicates which subjects are covered in the book and for whom they are useful. In this introduction, we’ll first look at what is expected of an IT architect.
1.1 Major tasks of an IT architect The application of architecture is supportive in nature. It is especially necessary when the business direction and the underlying IT landscape become so complex that they need an ordering design function to stay manageable and adaptable. The reason for IT architecture can be justified as follows: IT architecture delivers added value to an organization in terms of sustainable care for a consistent, future-proof and efficiently utilized IT landscape, in harmony with the organization’s process organization and information provision. This means that IT architecture is the deciding factor in the shaping (designing and developing) of an IT landscape and the facilities that have a place in this land-
scape. This is translated into the following tasks, for which the IT architect is responsible: 1 Vision development. How can an organization’s IT landscape be prepared for future changes in organization, business, laws and regulations, etc.? How can you deal with opportunities for technical innovation? What impact will these developments have on the IT services that an organization uses and what are the medium and long-term changes? 2 Determining the change needs and requirements for new solutions. What are the needs of the different stakeholders in a change and how can they be combined into one consistent set of requirements? Are there adequate solutions available, how feasible are they and/or how profitable will it be to implement these solutions? How will the security requirements of the facilities be ensured? 3 Design guidance. How are the needs regarding a solution translated into requirements for the design and directions for construction designers and builders? Where can causes be found if structural problems arise in the construction and how are they remedied? 4 Supporting decision-making. By guiding and facilitating the design process, architects can be of particular importance for decision making in an organization. Are all important stakeholders included properly in the design process? That is, how are you going to make sure that everyone understands what is intended
and how will you provide input that’s adapted to the role that people have and ensure that decision makers who count in the organization are able to make informed choices? The above tasks can be summarized by the term “digital spatial planning”. To do this in a structured and predictable way, some specific insights and skills are absolutely necessary. In other words, what does an IT architect need to do to make his work effectively? That’s what this book is about.
1.2 The insights and skills of the IT architect: how to read this book Useful methods, applied from a well-chosen perspective and embedded by good cooperation, facilitate work. But what’s more, they lead to results that are better supported and are proven to be more useful to the organization. Essential topics in the digital spatial planning that are discussed in this book are: • The role of architecture in the design process. Where and how does an IT architect make a difference in shaping and developing IT facilities and landscapes? • Making function models: the axis of architecture work. How do models facilitate the design process, how are they drawn up, how are they used to identify Chapter 1 introduction
| 15
relevant design issues on the one hand and how are they used to structure needs, requirements and directives on the other? • Examples of working with models to show what the design process looks like when function models are used. • Architectural products and their components – what products are useful for which situation and what target groups? With which (reusable) components are these products manufactured? • Embedding of architecture. How to organize optimal collaboration so that the architecture function is effective and efficient in an organization. The collaboration between (infrastructure) architecture and IT security has also been added. This is because critical decisions are often taken at this interface, which has an impact on the user-friendliness, adaptiveness and the security of the IT landscape. The following table indicates which topic is discussed in which chapter and for whom it is interesting. In addition to the chapters that describe or support the theory, this book also contains some personal stories from the field. These are intended as illustrations and are woven throughout the book. The themes that emerge are: • Development of OIAm and the role of the community; • Handling data center transitions; • Shaping of workspaces; 16 |
BRINGING IT ARCHITECTURE TO LIFE
• • • •
Working on Architecture repositories; Workplace politics: decision support; Functional tenders; Dealing with trends.
Chapter
Title
Description
For whom?
2
The role of architecture in the design process
Although design processes are creative and associative and, in many cases, iterative, it is completely possible to apply a structure. This can be divided into different continuums through the design process, which will be phased and iterative: a. the architecture continuum, where the design development is made; b. the solution continuum, where the construction design is formulated; c. the realization continuum, in which the physical form is fixed. Per continuum it is possible to start from a generic format (an archetype) to derive the specific application, the implementation in the context of the organization and the situation. The layout of the design process in continuums gives clarity on one hand and speed on the other. It helps us to make the right design questions in the right order and prevents repetition of implementation of existing solutions. This will be elaborated in the first part of this chapter. The second part focuses further on the architecture continuum. In the design phase, three steps are distinguished that ensure that function and quality requirements are retrieved, structured and translated unambiguously into directives that the construction should conform to. This is done by involving the right stakeholders, taking note of their needs and aligning them. This chapter clarifies the added value of architecture in the design process and how efficiently it gives direction, making sure that solutions are appropriate for an organization and that the needs of all stakeholders are taken into equal account.
IT Architects, Chief Information Officers (CIOs), Information Managers, Business Analysts, Requirements Managers, Project Managers, Buyers, IT Security, Technical Specialists, Developers and Administrators
3
The making of function models: the heart of architecture
Chapter 2 describes the important role of the architect in the design process. In order to be able to fulfill this role, experience in working with function models is strongly advised. These models have two advantages: they help identify key design questions and they support the structuring of stakeholder needs, requirements for services and directives for construction. This chapter provides the theoretical framework for creating function models. Depending on your preference, you can read this chapter first and then the chapter with a few examples (Chapter 4), or the other way around.
IT Architects, Requirements Managers, Technical Specialists, Developers and Administrators
4
Working with models: examples
This chapter is the counterpart of Chapter 3 and gives two examples of the use of function models. The first example starts from a technical perspective and shows how function models are created by reverse engineering the functionality in an existing situation and after that suggest the target architecture. The second example shows how function models are used to structure the needs of stakeholders into requirements for functionality and quality and translate them into directives for construction. In both cases, the complete production process is illustrated, with the most attention being paid to the phase in which the function design is drawn up: the architecture continuum.
IT Architects, Requirements Managers, Technical Specialists, Developers and Administrators
Chapter 1 introduction
| 17
18 |
Chapter
Title
Description
For whom?
5
Ingredients of architecture products
This chapter provides an overview of all the reusable components used for the composition of architecture products, as described in Chapter 6. Although useful and necessary, this is a chapter that – in comparison to the rest of the book – is more of a summary of character. It is especially useful when studying the detail of architecture work. Therefore, this chapter can be skipped in favor of Chapter 6, which presents a number of important architectural products.
IT Architects
6
Architectural products
An IT architect is expected to provide concrete products. These products must match the situation and the target group(s) that are relevant in the particular situation. For example, an Architecture repository is primarily intended for IT architects themselves as part of the work on architecture. Under architecture, some products focus on vision development for decision makers (such as a business infrastructure plans or roadmaps), while other products focus on projects and the teams involved (such as Project Start Architecture). This chapter lists the most important products, indicating which components are involved and which play a role in the manufacturing. Using this reference, it is possible to determine which products are most needed and/or the best suited to put the architecture function on the map.
IT Architects, Information Managers, Project Managers, Service Managers, CIOs
7
Embedding architecture
The best thing that can happen to an IT architect is that he or she is seen as an “indispensable oilman” or a “talented visionary”. However, in reality, there is resistance to or incomprehension of the architecture function in many organizations. Sometimes this has to do with the development phase of the organization. Sometimes it’s because of bad past experiences with the effectiveness of IT architecture which has caused a skeptical attitude. However, IT architects can achieve a great deal by thinking carefully about the way in which they collaborate with other IT disciplines. It is also important to give architecture a formal place in the (decision-making part of the) organization and to actively work towards the visibility of results.
IT Architects, CIOs
8
Infrastructure architecture and IT security
This chapter is specifically about the collaboration of (infrastructure) architects with IT security. While IT security is an absolute must for modern organizations, they continue to struggle with the impact of security measures on user-friendliness, adaptiveness and innovation. For this reason, it is very important that IT security needs are taken into account directly in the design process. This chapter promotes this as a further enhancement of the approaches offered by a wide range of IT security methods and standards that are available in the industry
IT Architects, IT Security Officers, Project Managers, Technical Specialists, Developers and Administrators
BRINGING IT ARCHITECTURE TO LIFE
Important concepts and definitions As in many other disciplines, IT uses specific terms that can have multiple meanings and associations. For a good understanding of what is described in this book, the most important concepts are listed here. An additional glossary is included at the end of the book. Service – The all-in-one functionality that is provided and/or experienced by users. ArchiMate calls this “external behavior”. Function – An operation that – possibly in conjunction with other operations – realizes a service. ArchiMate calls this “internal behavior”. A function comes to users indirectly, through the ser vice. Construction – The components and connections that perform functions seen as a whole. Principle – Overarching normative ruling that limits the design space. Model – A schematic representation (reduction) of a part of the factual situation, highlighting the aspects that are considered to be important for (design) statements about that situation. Stakeholders – Persons or organizational units which have a specific interest in the way in which services should be / have been realized within the organization. Requirement – Condition imposed by a stakeholder on the per formance of a service. This can be a form of functionality or a quality feature, such as availability, scalability or durability.
Continuum – A connecting whole within which a specific ap proach or a specific perspective is used. The term “continuum” is derived from TOGAF. Generation process / Development process – The process that adds new solutions to the IT landscape. Infrastructure is of ten spoken of as a generation process (through the merge of pro ducts and components of suppliers). When developing new ap plications, reference is often made to developing from application code, and this process is therefore called development. Design Process – The phased and iterative progress of a design activity.
Chapter 1 introduction
| 19
1.3 The main messages of this book This book contains a number of important messages. In order to prevent them from being lost on the many topics that are being discussed, they are explicitly stated here. Keep them in mind as you read further in the book. Clarity about functionality and quality has to come first, the construction follows later Consciously or unconsciously, almost everyone thinks in a “construction-oriented” way. A horizontal line and two shorter vertical lines below it will be interpreted by most people as a (very) abstract view of a table. But if you then ask them to describe the function of a table, it’s more difficult for them to come up with a clear answer. In the same way, it’s hard to talk about business and IT in terms of functionality. This also applies to quality aspects because it is complicated to formulate and quantify them (e.g. adaptability). However, for the architecture process, it is essential to start right here because both functionality and quality are the things that most stakeholders need to reach agreement on. The construction follows on from this. The art is therefore to switch the attention away from the construction and focus it on functionality and quality. Aside from the fact that design engineering is important to ensure the proper order, there is also a communicative aspect. If an IT architect succeeds in explaining 20 |
BRINGING IT ARCHITECTURE TO LIFE
functionality properly, anyone can talk and think about the requirements that are relevant and need to be reconciled, regardless of the (technical) IT knowledge they have. This avoids “technical emotion” when in discussion with people who do have a technical background and it helps to keep a “technology push” within limits. Every new development can be thoroughly tested for possibilities that are really interesting for the organization. Emphasizing the primacy of functionality is also important in situations where, for example, users or administrators already know about a product that they would like to see implemented – or, if they already use it as cloud service, which they want to integrate better. This product has usually been found when searching for certain functionality in the market. It’s actually a good idea to look closely at whatever a user group wants to make use of, or what they already use, because that tells you more about the functionality that’s needed. However, such a “product choice” may not be the end of the matter: it is always the beginning of a design process, even when it’s to see how a product already purchased should be integrated properly into the entire IT landscape. But, of course, the best effect of an architectural intervention is to result in a real design process (how brief and accelerated it may be) where other solutions are still open.
Use services as a connecting element for digital spatial planning If there is one concept that is suitable as the interface for communication between IT disciplines then it’s the “service” in the raw, pure form, which ArchiMate defines as: the functionality that provides a service, as used and experienced by the users. ArchiMate calls this “external behavior”.1 Services are realized by underlying “functions”, which ArchiMate describes as “internal conduct”. There are several reasons why the service lends itself well to connecting different IT disciplines: • The service concept gives a global description of functionality from the perspective of the user. Everyone can understand this description without the need for technical knowledge. A service is also the starting point for a more detailed decomposition of the underlying functions. • A service is consumed and deployed as a whole. The service concept therefore provides a perfect demarcation of facilities within the IT landscape. For service managers, it is the primary point where characteristics are linked and it is a recognizable entity for both buyers and suppliers. Project managers can make good use of the concept to determine the scope of projects.
1 Behavior can be both active and passive i.e. keeping data or enabling access. Therefore, in this book, the term “functionality” is sometimes used to indicate the whole of the behavior (both active and passive)
• At the core, the nature of services and (underlying) functions remains the same, independently of how they are delivered and constructed. Whether a service is being managed on-site or managed by cloud service, whether by virtualization or on a physical server, whether it is a Software Defined Data Center or a hyperconverged computing platform, it remains the same kind of service. Of course, there may be differences in features, but this has no effect on the nature of the service. This means that capturing an IT landscape from services and functions is very stable. When working with ArchiMate, a separate service landscape is set per domain (business, application and infrastructure domain). The link between the domains is primarily established by making connections between services. Figure 1.1 shows an example of a typical infrastructure landscape from a service perspective. Figure 1.1 shows that, with the help of services, a nice balance is found in the level of detail. It is clear that infrastructure offers much more than platforms, data transport and storage, but it remains easy to follow. Services can be decomposed into a number of underlying features that realize this service. A decomposition of services in features can be displayed in a model. With these function models, it is possible to address targeted design questions, to gather requirements in a structured fashion and to translate them into specifications of a Chapter 1 introduction
| 21
User Workspace
Connectivity
Collaboration
Computing
Data Management
Storage & Data Protection
Production Workspace
Datacenter Data Transport
Generic Application Hosting
Enterprise Service Bus
Central Mass Storage
Personal Workspace
Office Data Transport
Teleconference
Web Hosting
Database Management
Data Recovery
Printing & Scanning
Site Interconnect
Instant Messaging
Businss Rule Processing
Database File Handling
Archiving
Telephony
Cloud Interconnect
Presence
Calculation
Application File Handling
Platform Recovery
Knowledge Management Platform
End User File Handling
Deployment & Administration Platform Deployment
Application Deployment
Workspace Deployment
Network Management
Monitoring
Systems Management Platform
Internet Proxy
Data Transport Control
Security Authentication & Authorization
Identity Management
Security Monitoring
Figure 1.1 Example of an infrastructure service landscape
22 |
BRINGING IT ARCHITECTURE TO LIFE
Service Access Control
technical construction that should provide these services. In addition, the base structure of the function models is very predictable. The types of functions between which certain relationships exist are always the same. Each service is based on a recognizable basic structure. OIAm calls them “generic patterns”. Specific models can be made quickly using these generic patterns because the basic structure is already known. Work with well-defined architecture products where it is clear what purpose they serve What can an organization expect from an IT architect? How is the role fulfilled? The best way to make this concrete is to provide clarity about the architecture products that are being produced – in other words: you recognize the tree by its fruit. It helps to coordinate with clients which activities, processes and disciplines need to be supported. In many cases, architects are asked to support projects and project managers, for example, through Project Start Architectures (PSAs) and other forms of project guidance. This means that projects are being developed under architecture. In situations like this, it is advisable to capture and maintain Architecture repositories as a backing framework. This is working on architecture. The preparation of long-term visions with management managers is a bit of both. Therefore, architecture products are related to each other and they share common ingredients that are reus-
able. This makes it easier to develop different products at the same time. It is impossible to set up complex architecture products (such as Architecture repositories) at once. It is advisable to choose a good basic structure. As previously stated, service landscape overviews are particularly well-suited as the services are developed gradually and gain more detail as the project runs. In particular, integration facilities will be the first to ensure the consistency of the landscape from the perspective of architecture. Look for optimal collaboration in the organization for embedding the architecture function One of the biggest challenges for the IT architect is to create support for architectural practice in the organization. Perhaps it’s best if architects are able to achieve support for changes in the organization. This will align the needs of different stakeholders with the co-operation of the different roles in development and production processes. The trick is positioning the architecture function properly in the organization and accurately investigating which other roles within the IT organization can be supported in which ways. The paradox is that architects need to think in the role of the “other” instead of their own role. As an architect is strong when it comes to content (at least, this should be the case!), he/she is the right person to build bridges between the different disciCHAPTER 1 INTRODUCTION
| 23
plines. As no other, the architect is able to estimate, weigh and match interests. This sometimes requires a surprising attitude. If the architect picks the short-term problems in projects, this will assist the project leader. Of course, the reference point is the long term, and the architect must work with the project leader towards this. But only focusing on the long term without taking the project leader’s concerns seriously (who would like to complete the project within time, scope and budget) leads to frustration and incomprehension. In addition to project support, it is very important to maintain short lines with operational management and security officers, because these members of the IT company are essential for realization and continuity. Very often they are poorly involved in projects, mostly being consulted only during the end phase. It is important that the role of architecture is formally secured in a balanced governance structure. In addition, the aim should be for cooperation and responsibilities to grow and be invested from within, rather than enforcing top-level governance. This means that managers and architects consciously share responsibility. Both at the beginning, where architects inspire managers to shape a vision of IT development, and at the end, where managers take responsibility for decisions taken in architecture boards. The search for cooperation in all areas maybe the most important factor for the successful completion of 24 |
BRINGING IT ARCHITECTURE TO LIFE
the architectural practice in an organization, apart from the substantive expertise that is needed to get the job done. That makes working as an IT architect quite challenging, but also fascinating.
CHAPTER 1 INTRODUCTION
| 25
30 |
BRINGING IT ARCHITECTURE TO LIFE
THE ROLE OF ARCHITECTURE IN THE DEVELOPMENT PROCESS CHAPTER 2
The need to create a design increases when issues are complicated and multi-faceted, or when more stakeholders are involved. Designing is an associative and creative process: human knowledge and expertise are required. These insights and knowledge can remain implicit when going through a design process, being more or less unconsciously used by architects and designers involved. Although this is sufficient in some situations, developing a more structured and explicit way of applying insights and knowledge can have an important added value. Taking a methodical approach to support the associative and creative process ensures that results will be more transparent and predictable and they are often more complete and of a higher quality. In addition, this makes it possible to split design responsibilities which is very important, for example, in outsourcing projects where the technical specification, the design and management are performed by a supplier, but the ultimate responsibility of the functional and quality specifications are with the client. This chapter presents a vision of the role of architecture in a structured design process.
Chapter 2 the role of architecture in the development process
| 31
32 |
Within the design process, architecture is the discipline that is responsible for the overall design. In other words, it guides the design process in such a way that the final solution is as close as possible to the initial objectives and the context in which this solution is to be used, and it also fits as well as possible in the entire landscape of solutions and in the organization as a whole. An essential aspect is the structure of the design process itself and the phases within it that play a role. Another essential component is the involvement of all relevant parties (i.e. stakeholders) in the design process. In this way, an arrangement can be developed that meets the needs and demands of the different stakeholders as closely as possible. However, guiding of the design process is complicated for two reasons: 1 Interested parties have their own separate demands and preferences that are sometimes difficult to reconcile with one another, especially when the parties lack opportunities to express their needs. In addition, the requirements have to be formulated in such a way that they will be useful in the design process. Weill and Broadbent1 call this the “expression barrier” and “specification barrier”.
2 In reality, the appearance(s) can be so complex that it is difficult to bring order, to organize structures and to make the right design choices. Weil and Broadbent call these difficulties the “implementation barrier”. This brings the problems of incompleteness and ambiguity into play, as identified by De Wit and Meyer2. It is impossible to analyze a situation fully and unambiguously so that a defined, algorithmic process will result in an irrefutable outcome. On the contrary, the design process is associative and creative.
1 Weill, P. & M. Broadbent (1998). Leveraging the New Infrastructures: How Market Leaders Capitalize on Information Technology. Boston: Harvard Business School Press.
2 Wit, B. de, & R. Meyer (1999). Strategy Synthesis. London: International Thomson Business Press.
BRINGING IT ARCHITECTURE TO LIFE
There is an additional challenge when it comes to IT infrastructure: 3 When designing IT infrastructures, the construction and the technology used are usually the dominant factor. In addition, this technology is often complicated so many of the stakeholders will lack the knowledge to understand it or to make decisions about it. This last point particularly has led OIAm to start to focus on the ways of removing as many barriers as possible in the design process. Consequently, a focus on functionality and quality has been chosen within OIAm, as these are the most relevant aspects for most stakeholders. In
this way, the maximum freedom of choice is offered at the start of the design process, which can be narrowed down as the requirements become clearer. This also makes it possible to assess objectively if the construction meets the required functional and quality requirements at the end of the process. Substantively, OIAm makes use of models, so that the discussions with stakeholders and the bringing forward of explicit design choices can proceed in a structured way. The process of making models is described in the following sections, but this chapter focuses first on the role of architecture in the design process, where OIAm structures the design along three continuums. To the first continuum, which addresses the function design, another dimension is added by structuring this continuum with a number of consecutive steps that enable the translation of stakeholder needs into requirements and specifications. The division of the design process is as follows: 1 Phasing of the development process: the OIAm-development continuums; 2 In detail: steps in the function design phase. These two dimensions are further explored in the remainder of this chapter.
2.1 Phases of the design: the development sequences Due to their responsibility for the overall design, OIAm visualizes a leading role for architecture early in the design process. Then, as the design progresses, it shifts to a more supporting role. This concept is based on the work of prof. Dr. Gerrit Blaauw.
Gerrit Blaauw, born in 1924 in The Hague, was a computer pioneer who helped to design several large computer systems. The best known was the IBM Systems / 360 mainframe, which was the first 8-bit computer and the first mainframe that could be used both for commercial and research purposes. In his work, Blaauw developed a set of methodical design principles which he documented at the end of his career in his book Computer Architecture: Concepts and Evolution. This was published in 1997 and was based on his various articles and lecture notes on the subject.
Blaauw distinguishes three consecutive steps in the development process of a computer: Architecture, Implementation and Realization. He describes these steps as follows: “Architecture concerns the function that is provided to the programmer, such as addressing, addition, interruption, and input/output. Implementation concerns the method which is used to achieve this function, per-
Chapter 2 the role of architecture in the development process
| 33
haps a parallel data path and a microprogrammed control. Realization concerns the means used to materialize this method, such as electrical, magnetic, mechanical, and optical devices and the powering and packaging for them. Therefore, the realization also includes the visual appearance, the industrial design of the computer.�3 The distinction made by Blaauw in architecture, implementation and realization is further elaborated by OIAm by bringing in two directions. Firstly, three consecutive phases are identified in the design process. These are in line with the three divisions suggested by Blaauw, but to make it clearer, they have been renamed as the phase of the function design (architecture continuum), the phase of the construction design (solution continuum) and the phase of realization (realization continuum). Secondly, the movement of a generic, universal structure to a specific interpretation is identified and separately recognized at each stage. This means that, at any design stage, it is possible to move towards an application that matches the (user) context and the specific requirements identified in this context from the generic, archetypal principles and patterns. This is represented as a diagram in Figure 2.1.
3 Blaauw, G.A. (1990). The persistence of the classical computer architecture. CWI Quarterly, Vol. 3, No. 4, pp. 335-348. Amsterdam: Stichting Mathematisch Centrum (Centrum Wiskunde & Informatica).
34 |
BRINGING IT ARCHITECTURE TO LIFE
In this classification of continuums, two points should be emphasized: 1 Although a flow is applied in the development process, it stays iterative. In each continuum it is possible to go back to any stage to add other archetypes and/or principles if necessary or to go through the earlier sequence(s) again. 2 This division of the development process is independent of the size of the design scope. It works for both large-scale and small design assignments and allows them to be sub-divided into separately handled parts. To further explain how the classification of the continuums work, the process shown in Figure 2.1 is applied to the example of a station clock (see Figure 2.2). This example is also used by Blaauw. By using the same example, the similarities with and differences between the workflow of Blaauw and the continuums of OIAm are further illustrated. The first phase in the development process is the functional design (architecture continuum). The function of the station clock of the station function is the same as all other clocks: namely time display. However, the specific application adds additional characteristics.
Archetype
Architecture Continuum
Solution Continuum
Realization Continuum
Generic function(s)
Core structure/ topography
Generic components/ items/library
Implementation
APPLY
APPLY
APPLY
Specific function(s)/ core structure
TRANSLATE
TRANSLATE
FEEDBACK
FEEDBACK
Specific construction/ blueprint
Specific build/ part/code
Figure 2.1 Schematic overview of the sequences on the iterative development process
Chapter 2 the role of architecture in the development process
| 35
Archetype
Architecture Continuum
Solution Continuum
Realization Continuum
Indication of time
Mechanic movement
Mechanic movement – Mobatime DMU 160
Implementation
APPLY
APPLY
APPLY
Platform Time Indication
TRANSLATE
TRANSLATE
FEEDBACK
FEEDBACK
Station Clock Blueprint
Station Clock Platform 2A
Figure 2.2 The example of the station clock illustrating design approach
There are special demands according to the perspective of each stakeholder and their needs. The clock has to do the following: • Clearly indicate the time; different clocks should show the same time to avoid confusion (passenger perspective);
36 |
BRINGING IT ARCHITECTURE TO LIFE
• Be able to withstand vandalism (manager/owner perspective); • Be easy and inexpensive to mass produce (owner perspective); • Be easy to manage (administrator).
The stated demands (in the jargon known as “requirements”) are a mixture of further functional specifications (such as synchronization of the time shown) and quality (robustness or integrity and manageability). The way in which time can be displayed has a number of different formats (or base structures), such as a sundial, an analog clock or a digital clock. Because the choice between them is very important for design questions and choices (including functional), it is vital to think about the different formats when defining the functional specification. In the case of a station clock, a sundial is immediately out of the question because the conditions inside stations are unsuitable. When deciding between a digital or analog clock, there is the consideration that an analog clock is easy to read from a distance without mistakes, whereas the numbers 5, 6, 8 and 9 are very much alike in a digital clock, so it is not so easy to read. In the context of a station, the needs of the train users largely determines the usefulness of the station clock. Due to the considerations that apply to the time display functionality in the context of the station, the following design choices are made: • The time display will be configured as an analog clock with a dial that gives an indication of the hour, minute and second. This is important for the main user of the time display, the train user.
• To keep the production and management cost down, a robust but simple timepiece has to be selected. This is in the interest of the owner of the clock, the railway company. • Clocks are synchronized centrally. Because the movement is simple and therefore less accurate, this has to happen a) regularly and b) from a central “Master” clock by means of a network synchronization signal sent to all the “Slave” clocks on the platforms. Synchronization per minute is selected, so that the beginning of each whole minute is clearly indicated. So, the interests of the train traveler (accurate time display) and the owner (cost effective solution) and the manager (little management effort needed to adjust to the time) are met. In this way, the requirements, derived from the different stakeholders needs, are translated into guiding statements for the following continuum in the development process, the phase of the construction design (solution continuum). These guiding statements work as requirements for construction design. It is important to note that this must be done in a way that is as accessible and meaningful to all concerned. All stakeholders have a say on functionality and quality, with the requirements for the construction design presented, as far as possible, in a technology neutral way. Nevertheless, this is of great informational value for the construction designer, who
Chapter 2 the role of architecture in the development process
| 37
can apply a standard construction method for mechanical timepieces, because it is also possible to make use of generic, universal principles in the solution continuum. Any mechanical movement has certain technical features that occur in every timepiece of this type, such as the way the drive shafts are integrated for the different pointers or how the central synchronization mechanism operates. The construction designer uses this as a starting point when creating a specific structure design, together with the previously mentioned directives from the previous design. Below are some examples of choices in the construction design: • The clock gets a short hand for the hours which goes round continuously. • The clock gets a long hand for the minutes which jumps per minute (departure times are always full minutes). • The clock gets a seconds hand which goes around continuously. • The housing is robust. • Due to the synchronization per minute, the seconds hand must have a revolution time which is slightly less than one minute, so that it waits for the synchronization signal before continuing. These principles are reflected in the final result, a construction design or blueprint. By creating a blueprint, the construction designer will also make choices regarding 38 |
BRINGING IT ARCHITECTURE TO LIFE
the components to be used for the final realization. In general, standard components which are available in the market as a catalog item will be selected, unless the requirements are so unusual that custom components have to be manufactured. With the delivery of a blueprint and a list of the necessary components, the development phase is completed and leads to the final continuum of inputs, the phase of realization (realization continuum). In the realization continuum, the required items will be ordered and a specific example is put together from the components. The result of the realization continuum, as part of the design process, is a prototype which usually serves as an example for many successive copies which are manufactured in production. In some cases, after a test phase, the prototype is itself the operational copy, when no other copies are required, such as in the establishment of a network. The purpose of using the continuums is to ensure that the design process can run in a structured way. Requirements are collected effectively and implemented during the subsequent design phases. The continuums make the design phases explicit and make it possible to apply iteration. So when, in a later stage, new issues in the design come to light (for example, when technical limitations are encountered), then they can be related to earlier stages of design. In this way, the design is refined. From the perspective of OIAm, the “center of gravity” of the architecture practice is in the first phase of the
design process, the functional design. An objective of OIAm is that all stakeholders have an equal say at this stage. Because infrastructure is often discussed in technical terms, an additional ingredient is required, namely terms with which the functionality of infrastructure can be expressed. These terms are discussed in Chapter 3, which deals with the creation of functional models. Of course, architects also play a role in the second and third continuum, but that role is more in the background and focuses on design guidance. Creating a design structure is primarily the responsibility of the technical specialists. Architects will assist in translating the requirements identified in the first phase into the technical construction working towards a concrete structural design. This can be done by clarifying the requirements (the background for them) and any necessary iterations of the functional design when design requirements are difficult to meet, for example, because of previously unforeseen technical complications. When realizing a solution, architects are responsible for checking whether the planned solution meets the requirements. Again, they can provide support for an iteration in the design to allow for adjustments, which may prove to be necessary during construction. The division into continuums serves yet another purpose. The scope is reduced when standard services are available, and this means that the process through the first two continuums will be mainly to check if the
default services are sufficient for the intended application. In such a case, the flow is “from out to in�. Appendix C provides a list of common service arrangements of services that are usually made in combination with each other. These are available as ready to use standards from various cloud providers.
Chapter 2 the role of architecture in the development process
| 39
48
The role of the community A community has evolved around the development of infrastructure architecture, which happened more or less by accident. When OIAm was still DYA | Infrastructure, I began to notice some things in response to a number of landscape inventories (called “global taxonomies” at that time; a sort of lightweight Architecture repositories). I saw that not only did the same functions show up repeatedly in the analysis, but that these functions also appeared to be in comparable relationships. Therefore, in the summer of 2009, I invited a number of colleagues from different organizations to a series of exploration sessions. The purpose of these sessions was to capture and document a number of patterns of coherent functions. Within a small group of about 6 people, we laid down the first eight basic patterns. It was only blocks and lines at that point; the discovery that ArchiMate would be a good starting point for making models came later on. After the collection of more patterns, an online library was created and published which was a copy of a wiki that had been set up for a major client. To this day, I am grateful to this client for his generous attitude. It is this attitude that ensures that actual innovation takes place and by sharing success, success is multiplied. In addition to the wiki, there was a mailing list, a LinkedIn group and a community. As an experiment, we organized a community meeting on location with another client. And at this first meeting, no less than 40 colleagues turned up! Although the meeting was organized on a very modest scale (we brought our own drinks and snacks with us), it was immediately obvious that here was a need to be met. Gradually, the numbers of attendees at each session has grown into the low hundreds. That’s quite something, if
49
Traffic Filtering
Standard facility Optional facility
Intrusion Prevention/ Detection
Adjacent pattern facility Connection/interrelation
Load Balancing
Optional Connection/interrelation Portal Authentication Reverse Proxy
Encryption Endpoint
Authorization Traffic Filtering
Load Balancing
Presentation
Web
Authentication
Application Platform
Authorization
One of the patterns from the first hour
50
Compression Endpoint
you look at the size of the target population. At a National Architecture Congress, usually about five hundred visitors come from all kinds of architecture disciplines and other IT functions. Here, infrastructure architects and specialists form a small minority. The meetings are still the backbone of the community: actual meetings and the opportunity for direct exchange of experiences and ideas remain the engine that keeps us going. The contents of this book have also been reviewed with community members in special sessions. Using different forms of social media for community support has proved difficult. Tracking and moderating often rests on the shoulders of a few enthusiasts and the frequency with which people check if something is new is quite low. This also applies to the online wiki, the OIAm repository. It may take a long time before new insights, patterns, and definitions are placed in the repository. This is partly due to the fact that both comments and additions need to be provided by the community, as well as support for those changes, which seems difficult to organize. Undoubtedly, this type of channels will only function properly when the size of a community exceeds a certain critical limit. It is therefore my hope that more and more people will share their own experiences with others. For me, that is one of the most important ways in which the professionalization of a line of work can be developed further. Community gathering in the Holland Casino, including a visit to the ‘work floor’, 2012
51
The complexity of modern IT landscapes forces organizations to implement changes and innovations in a well-defined and structured way, applying architecture. But that’s easier said than done, because how do you actually bring IT architecture into practice? What are the tasks of an IT architect? What methods and tools are available to an IT architect? What products does an IT architect deliver? And how do you make sure that these products are effective and offer added value to an organization? In short, what does it mean to be a full IT architect? This book is a practical guide for today’s digital architect and offers inspiration for a fuller understanding of the subject. The “what”, the “why” and the “how” are discussed extensively both in terms of the design, as well as in the creation of architecture products and the successful establishment of the architecture function in the organization. This book is also of interest to other disciplines who want to understand more about how architecture works. By weaving personal practice stories throughout the book, the author presents a true “living” picture of the role of IT architecture.
Daniël Jumelet (1973) is a pioneer in IT architecture, constantly looking for innovation and improvement as he works with colleagues and clients. It is his passion to share his years of experience in the subject he practices with all his heart and soul.
| 49