Colophon

©2018 Daniël Jumelet

ISBN 978 94 92190 89 5
ISBN epub 978 94 92190 90 1

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.
TOGAF™: X/Open Company Limited trading as The Open Group
AgilePM®: Dynamic Systems Development Method Limited

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the publisher's prior consent.

Note on the publication of the e-book

Ideally, a book with architecture as its subject should look terrific, with lots of attention paid to its layout and visual aspects. The original paper version of this book was created in this way, but because I wanted to make its content easily accessible, I've chosen to offer a digital text version as well. I hope reading this e-book will be inspirational and joyful. If so and if you would like to experience the power of this book to the fullest, please consider ordering a paper copy. The best way to obtain your copy is by paying a visit to the publisher's webshop. A digital preview is available there.

Every purchase benefits the further development of the practice of architecture. Publishing the book has been an investment which is still waiting for its return. So, if you have enjoyed this book, please encourage others to obtain their own copy or order a paper copy. Many thanks in advance, and I wish you a lot of success in your profession!

Preface

One of the things I enjoy most in life is sharing knowledge and expertise with others, in order to discover new insights together. This is why I created this book: as a record of how I found my way in practicing IT architecture. My technical background is IT-infrastructure and from the beginning it was clear that, when it comes to the necessity of discoveries and pioneering, that domain is one of the most challenging ones. It is the domain that is almost exclusively occupied by specialists in most organizations and is very hard to grasp for people in other areas of expertise. Additional efforts are needed in order to work effectively together with different disciplines and a broad range of stakeholders and to create a comprehensible discourse regarding the design and development of infrastructure landscapes. Emerging from this need, the Open Infrastructure Architecture method (OIAm) came into being. OIAm is an approach that tries to express and define infrastructure in terms of functionality and quality, as leading concepts that direct the construction design.

In my opinion, much of what has been developed in the context of OIAm is useful in other domains. What's more, using and fine-tuning the approach has fostered practices that are beneficial to the application of IT architecture as a whole. All this has all been put together in this book, which is meant as a practical guide for everyone that practices or intends to practice the IT architecture profession. As regards its methodical background, this book is based on OIAm and infrastructure architecture. It continues with substantial attention to the semantics as proposed by ArchiMate®, which is used by OIAm in the creation of function models. Also, explicit connections are made with TOGAF™, DYA® and DEMO® architecture methods. The structure of this book aims to enable the combination of practices that are provided by these methods and all kinds of other approaches. In my experience, most IT architects have a toolkit filled with all kinds of useful ways of working. Let's be frank about this: in the current state of development of our field of work, divergence should be promoted as it serves as a source of innovation.

This book presents a number of topics that are important for a professional job fulfillment and effective execution of the most significant tasks. That's why a great deal of attention is paid to the design process, the role of architecture in this process and the creation of function models to support this. This section is mostly derived from OIAm. Another section is dedicated to the creation of architecture products and the (reusable) ingredients that are needed for this. Cooperation with colleagues and other IT disciplines is another aspect that is very important because it is necessary for the acceptance and effectiveness of the practice of IT architecture, that is why this is worked out extensively. Together with the theoretical foundation, a special storyline of personal, practical narratives is interwoven throughout the whole of the book. A special chapter is dedicated to the interconnection of IT security and IT (infrastructure) architecture, as important decisions need to be made on the cutting edge of those disciplines regarding usability, innovativeness and security.

The book can be read in different ways: as introduction to OAIm, as practical guide for the application of IT architecture, or as an insight into the ways of a fellow practitioner. I leave it to you, the reader, to decide what you will take away and encourage you to combine whatever you find with your own practices as much as possible. I hope this will encourage new insights in this profession, as this is the very intention of this book.

In my opinion, our profession still needs to advance and to develop, in all aspects a structured, methodical way of working needs to be elaborated. This book is just a part of this quest, created because I know how important IT actually is for organizations. In a world with growing complexity, the need for orderly and structured design, provided by IT architecture is ever greater. Apart from the result, the way these designs are crafted is also very important, involving all stakeholders so that solutions fit with the goals and character of organizations. A mature design process enables every stakeholder to express needs and concerns within the dialog that leads to supported solutions.

In many countries, such as the Netherlands and Great Britain, the use of the title IT architect, Business architect, Information architect, Application architect, Infrastructure architect or any other related form, lacks a legal basis. In these countries, the law recognizes only structural design as the profession carried out by architects, where the title 'architect' is protected and limited to this kind of profession. To qualify for this title, architects need to accomplish a long, thorough academic study and enrolment in a professional register based on the delivery of a proof of craftsmanship. It is the task of those registers to enforce the rules of admission and to actively counteract the unauthorized usage of the architect title. Many registers have stated that they will not dispute the usage of the architect title in the field of work of IT, as long as it is made clear that this title is used in a different context, not referring to structural design and avoiding any possibility of confusion in the market. At the same time, they urge IT professionals and IT architect communities that seem to be so eager to use this title to actively work on the professionalization of this field of work and legalize the usage of this title in the context of IT. This can be accomplished by the establishment of proper educational circumstances and creation of a broadly valued certification. As far as I am concerned, we should accept the status that fits with the current level of IT architecture, as well as doing all that is in our power to advance our profession and raise it to the highest possible level.

Architects in the "real, lawful" meaning of the word (i.e. structural designers) are very well equipped to communicate with both originators, as well as suppliers and building companies. It is their role to build the bridge between demand and supply in a substantial fashion. This starts with the elicitation of the demand of originators and the identification of all relevant stakeholders in a project. By creating a design, a solution finds its form in a structured way, in an iterative, interrogative process with originators and all involved parties and people. Using the design as basis, feasibility is analyzed and construction alternatives are defined. Together with suppliers and builders, the technical realization is elaborated and guided. It is the role of the architect to have an oversight over the whole process, to safeguard the proper fit of the solution in the given context and ensure that the construction will fulfill all requirements regarding usage, maintenance and security.

In this sense, architects are needed in the digital world too, as "overarching designers". But how can they play that role? What way of working should be adopted? What products do they deliver and to whom? How can they create added value to the organization(s) they are working for? There are many questions. For anyone who wants to play a role in the design and development of IT landscapes of real world organizations, I want to share my experience to offer guidance in answering these questions with this book. In this way, I hope that it will inspire a further development of a profession that achieves its best results by serving others. Most importantly, I hope this book will be of service to you!

Culemborg, May 2018

Inhoud

Cover

Colophon

Note on the publication of the e-book

Preface

Chapter 1 Introduction

1.1 Major tasks of an IT architect

1.2 The insights and skills of the IT architect: how to read this book

1.3 The main messages of this book

Personal practical stories

A few asides

Chapter 2 The role of architecture in the development process

2.1 Phases of the design: the development sequences

2.2 In detail: steps in the architecture continuum

2.3 Involvement of stakeholders

The role of the community

Chapter 3 The making of function models: the heart of architecture

3.1 Patterns

3.2 A lexicon for infrastructure functions

3.3 ArchiMate: a semantic for the modeler

3.4 Application of the OIAm model approach outside of the infrastructure domain

Handling data center transitions

Chapter 4 Working with models: examples

4.1 Example 1: The Exchange migration

4.2 Example 2: Identity Management for cloud solutions

Design of workplace services

Chapter 5 Ingredients of architecture products

5.1 User stories

5.2 Service descriptions

5.3 Quality aspects

5.4 Environments

5.5 User categories

5.6 Principles

5.7 Architecture Building Blocks

5.8 Artist's impressions

5.9 Solution Building Blocks

5.10 Threat analyses

Working on Architecture repositories

Chapter 6 Architectural products

6.1 Organization Context Analysis (OCA)

6.2 Business-IT plan, roadmap and project calendar

6.3 Architecture repository

6.4 Business case / impact analysis / feasibility study

6.5 Project Start Architecture (PSA), Sourcing Start Architecture (SSA) and Solution Foundation

6.6 Root cause analysis

Functional tenders

Chapter 7 Embedding architecture

7.1 Goals

7.2 Processes

7.3 Roles

7.4 Architecture products

7.5 Strategic partners

7.6 Governance

7.7 Making architecture visible

Office politics: decision support

Chapter 8 Infrastructure architecture and IT security

8.1 Strategy determination

8.2 Threats and risk analysis

8.3 Mitigation

8.4 Example of a threat analysis

8.5 Security Management

8.6 Privacy protection

Coping with trends

Appendix A Introduction to OIAm

A.1 What is OIAm?

A.2 The focus of OIAm

A.3 What does OIAm offer?

A.4 History of OIAm

A.5 What remains outside the scope for OIAm?

Appendix B Modeling protocols for the application of ArchiMate

B.1 The use of ArchiMate

B.2 Preferred concepts in infrastructure

B.3 Relationship conventions

B.4 Relationships between views and layers

B.5 Level of detailing

B.6 Agreements about naming

Appendix C Cloud Service Packages

C.1 Application Hosting

C.2 Web Hosting

C.3 Calculation

C.4 Data Management

Glossary

References

Acknowledgements

Daniël Jumelet

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 specific 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 architecture). 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 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, 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 landscape. 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 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;
• | 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

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

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 service.

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 performance 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 approach 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 often spoken of as a generation process (through the merge of products and components of suppliers). When developing new applications, 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.

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 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".¹ 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.

•
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 Example of an infrastructure service landscape

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 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 reusable. 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 disciplines. 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 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.

Note

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)