3.1  Introduction

To keep up with the rapid changes happening in technology, markets and society, enterprises must be flexible and adaptive. This flexibility must be designed into the structure of the enterprise. In accordance with The Open Group, we consider an enterprise any organization of people, processes and means that share a common goal [1]. Thus, an enterprise can be a company or institution, but it can also be part of a company or a network of cooperating parties. An enterprise is a complex system, acting in a complex environment with many types of stakeholders such as customers, shareholders, partners, suppliers, jobseekers and regulators.

Enterprise architecture is the discipline that concerns itself with designing the structure of the enterprise. The aim of enterprise architecture is to translate the ambitions and strategy of an enterprise into guidelines on how to structure the necessary processes, information systems and technology, to enable the continued realization of the strategy. It takes a holistic view of the enterprise, looking for a seamless integration of products and services, processes, information flows and technology.

A widely adopted definition of architecture is the ISO/IEC 42010:2007 definition, which defines architecture as “the fundamental organization of a system embodied in its components, their relationships to each other and the environment, and the principles guiding its design and evolution.” This definition indicates that enterprise architecture is about components, relationships and principles. In the case of enterprise architecture, the system is the entire enterprise. The components, an enterprise is made up of, are of various types, such as organizational components (departments, roles), processes, data and information, and technology (software, hardware). In this definition, enterprise architecture is regarded as an artifact, i.e. the models and principles defining the enterprise. When we talk about the development and application of the models and principles, we speak of enterprise architecture management.

3.3  Architecture frameworks

Over the decades, the views on position and goal of enterprise architecture have evolved. In the 1980s, architecture was regarded as part of information planning. An information plan often had a scope of up to five years. The architecture had the form of a blueprint, was all-compassing and based on the idea that the world is malleable. In the 90s, IT architecture is no longer considered part of an information plan, but as a set of principles and models that exist in their own right and must be maintained. The aim of the IT architecture was mainly standardization in IT. Attempts were made to address organizations’ wishes for more rapid change, but that appeared difficult. Around 2000 realization dawns that architecture should be not only about IT, but also about processes and products and services: business architecture is born [5]. Models are made distinguishing front, mid and back office, and customers, channels and products, organizations move from product-oriented to process-oriented, etc. Gradually, it becomes clear that business and IT architectures should be integrated in an enterprise architecture covering all aspects of the organization: products/services, processes, organizational structure, information flows, applications, middleware, hardware and network technology must be considered together. One cannot be seen separate from the other.

Over the decades, various architecture frameworks have been developed to guide the development and application of enterprise architecture [6]. These frameworks support the architects in doing their job. They provide structure as well as a common language between architects. Architecture frameworks differ in focus and in their perception of architecture, but most frameworks have in common that they make the connection between strategy and solutions and distinguish various perspectives. Most frameworks distinguish in some way or another between the perspectives of business, information systems and technical infrastructure. Dependent on the focus of the framework, attention may be paid to the architecture artifacts, the architecture processes and/or the organization of the architecture management function.

One of the first architecture frameworks was the Zachmann Framework [7]. The Zachmann Framework focuses on the enterprise architecture artifacts. It provides a logical structure for classifying and organizing the descriptive representations of an enterprise, covering the entire set of descriptions necessary to describe an enterprise, or any other system. The Zachmann Framework is a two-dimensional matrix. The horizontal axis is based on the interrogatives What, How, When, Who, Where and Why. The vertical axis is based on the transformation from an abstract idea into instantiation: Identification, Definition, Representation, Specification, Configuration and Instantiation, which represents the perspectives of different stakeholders. This provides a matrix in which the 30 cells represent the classification of the framework. The framework purports to be normalized, complete and stable. The normalized primitives (the cells) can be combined into composites needed to “build” a working enterprise. The framework enables focusing on one component, without losing track of the complete picture and the context in which the component exists. The Zachmann Framework is considered by many the mother of all EA classifying frameworks. Besides the Zachmann Framework, various other similar frameworks have been developed, sometimes for specific domains. In practice today, Zachmann is more of a reference framework than an integrated framework that is implemented.

In the early 90s, TOGAF™, which stands for The Open Group Architecture Framework, was launched. TOGAF is developed and maintained by The Open Group Architecture Forum [8]. The first version of TOGAF was developed in 1995. The core of TOGAF is the Architecture Development Method (ADM), which describes the various phases in architecture development. It starts with a preliminary phase, in which the foundation is laid by tuning the framework to the organization and defining the foundational principles for architecture. After this groundwork, a cycle of eight phases is executed for each change initiative, the first phase being the definition of an architecture vision and the last phase the execution of architecture change management. TOGAF distinguishes four types of architecture as part of an enterprise architecture: business architecture, data architecture and application architecture (together referred to as Information Systems Architecture in the ADM) and technology architecture. The ADM cycle can be applied at various levels, such as the enterprise level, domain level or program level. It always starts with a need for a (business) change. Besides the ADM, TOGAF provides a lot of practices for enterprise architects to use, including guidelines and techniques to support the application of the ADM, the Architecture Content Framework that provides a detailed model of architectural work products, the Enterprise Continuum that provides a model for structuring a virtual repository and classification of architecture and solution artifacts, the TOGAF reference models: Technical Reference Model and Integrated Information Infrastructure Model, and the Architecture Capability Framework to help establish an architecture practice within an enterprise. TOGAF is an extensive framework with many useful practices from which an enterprise must make its own selection. The ADM provides a clear structure to the architectural processes.

ArchiMate is a modeling language. It was developed between 2002 and 2004 for architecture modeling and aims to contain all concepts that are relevant to describe an enterprise architecture [9]. The core concepts of the language are classified into aspects and layers. A concept may be labeled an active structure element (e.g. business actors or application components), a behavior element (e.g. business process or application function) or a passive structure element (e.g. business object or data object). A concept also belongs to one of three layers: business layer (e.g. business actors or business processes), application layer (e.g. application components or data objects) and technology layer (e.g. infrastructure function or node). The most recent version saw an extension of two additional layers: strategy and physical. Besides the core concepts, ArchiMate distinguishes concepts related to motivation, such as driver, goals and principle, and to migration, such as plateau and deliverable. A very important concept in ArchiMate is the service. The service is the externally visible behavior of a system. It is also the glue between the layers. Thus, the infrastructure layer is accessed by the application layer via infrastructure services. Similarly, the business layer can use the functions of the application layer via application services. The business layer delivers its services to the environment via business services. In 2008, ArchiMate was transferred to The Open Group. ArchiMate is an architect’s tool. It is very useful for accurate modeling as well as for communication among architects and designers. It is less suitable as a means of communication toward management. ArchiMate is supported by many modeling tools, including freeware.

In the 80s and 90s, the primary focus of most architecture frameworks was on the architecture artifacts. As a reaction to this, in 2002 Dynamic Architecture (DYA) was launched [10]. DYA focuses on the architecture process and on how to effectively apply architecture to realize strategic goals. It distinguishes four main processes: strategic dialogue, architecture services, development with architecture and development without architecture. The leading principles of DYA are a just enough, just in time approach, i.e. only developing architectural artifacts where and when there is a need, and the embedding of architecture in the change processes of the enterprise. DYA contains various instruments, such as the project-start architecture, an architecture artifact that tunes the enterprise architecture to the specific context of a project.

In more recent years, new frameworks were introduced, such as General Enterprise Architecting (GEA) [11] and Risk- and Cost-Driven Architecture (RCDA) [12].

Architecture frameworks are designed from the perspective of the architect. However, architecture is not a goal, but a means to achieve the business goals. To this end, architecture must be embedded in the change processes of the organization. These change processes recently underwent considerable changes with the rise of Agile development. With Agile, the focus shifted from central governance to autonomous development teams, with little or no room for architecture. Many of the premises of the existing architecture frameworks were no longer valid and architects struggled to establish new ways of working, adapting to the new development paradigms. Gradually, however, a new way of collaboration between architects and agile teams is emerging.

One Agile development framework that positions architecture within Agile development is SAFe®. SAFe® stands for Scaled Agile Framework [13]. It is developed and maintained by Scaled Agile, Inc. It is a scalable and configurable framework based on Lean-Agile principles and values. It helps organizations “deliver new products, services, and solutions in the shortest sustainable lead time, with the best possible quality and value… It provides guidance for the roles, responsibilities, artifacts, and activities necessary to achieve better business outcomes” ([14], p. 1). SAFe combines Agile, Lean product development and systems thinking. It is used to synchronize Agile teams. It distinguishes various configurations ranging from Essential SAFe containing the basic building blocks and most critical elements, to Full SAFe that is used to build large solutions and contains the levels of team, program, large solution and portfolio. One of the framework’s fundamental principles is to decentralize decision-making. Arguments for this are among others that decentralized decision-making reduces delays and improves quality of decision where local knowledge is involved. This is not to say that central decisions are not necessary at all. However, they are far less frequent and limited to strategic decisions, i.e. decisions that have far-reaching impact and are outside the scope or knowledge of the teams. Examples of such decisions are decisions about product strategy or the standards to be used.

SAFe aims to break the functional silos by creating teams of Agile teams in the form of an Agile Release Train (ART). An ART is a networked organizational structure that is self- organizing and self-managing. In the ART teams, key stakeholders and other resources work toward an important ongoing solution mission. They share a single vision, roadmap and program backlog. ARTs deliver features (user functionality) and enablers (technical infrastructure). The ART is positioned at program level. At this level, the role of the system architect is recognized. The system architect defines the overall architecture for a system, helps define nonfunctional requirements, determines the major elements and subsystems, and identifies the interfaces and collaborations among them. Above the program level, SAFe distinguishes two other potential levels: large solution and portfolio. The large solution configuration is meant for complex solutions spanning more than one ART. At this level, the solution architect is the one that defines a common technical and architectural vision for the larger solution. The portfolio configuration aligns portfolio execution, organizing development around one or more value streams. At this level, the enterprise architect works across value streams and programs to provide strategic technical direction and often acts as the epic owner for enabler epics.

In SAFe, architecture is not regarded as something that must be defined centrally in a top-down fashion. Instead, there is a need to balance emergent design and intentional architecture. Emergent design allows designers to respond to immediate user needs, intentional architecture takes care of matters that are beyond the scope of the team and provides guidance for inter-team design and implementation synchronization. Intentional architecture constrains emergent design, but only to the extent necessary, leaving enough room for maneuver for the teams. Emergent design corrects and feeds intentional architecture. Emergent design and intentional architecture together build the Architectural Runway, the technical foundation for future creation of business value. This only works if there is true collaboration between teams, architects and product management.

SAFe has a very different approach to enterprise architecture than TOGAF, giving it a more supportive role instead of a controlling role as is the case in TOGAF.

3.4  Thinking in services

An increasingly important concept within architecture is the concept of service. A service is a discrete unit of functionality that is well-defined, self-contained and remotely accessible, and does not depend on the context or state of other services. Services are defined by their interface, abstracting away the underlying implementation, which makes it easier to change the implementation of a service without disabling its use. The collaboration of services is often done by an orchestration function. Services can be internal to the enterprise or external. External services may reside in the Cloud. A service registry enables the publication and retrieval of available services. The concept of service can be applied at various levels, ranging from business services such as on-line payment services to application services such as financial administration to infrastructure services such as storage space. A Service-Oriented Architecture (SOA) consists of services that jointly achieve specific results [15].

A recent further development on the service-oriented architecture is the microservices architecture [16]. A microservices architecture structures an application as a collection of loosely coupled microservices. Microservices are services organized around business capabilities that can be independently developed and are independently deployable and scalable. Scalability is achieved by running multiple instances of a microservice. There are various infrastructural solutions for this, such as containers or serverless deployment. Microservices can be implemented using different programming languages, databases, hardware and software environment per microservice, depending on what best fits the specific microservice.

SOA, and its successor microservices architecture, has gained great popularity over the years because of its modular approach which provides the potential for flexibility. Therefore, it is very suitable to enable a sourcing strategy.

3.5  Enterprise architecture and digital sourcing

Digital sourcing is about the ability to flexibly combine digital capabilities provided by different parties, in offering propositions to the market. These digital capabilities, offered as services, can be of very different types, varying from managed applications in the Cloud (SaaS), providing scalability, to the delivery of back-office business services, such as salary administration, providing efficiency, to the provisioning of new customer interaction, by data-analytics, gamification and/or chatbots, providing better service to customers, and everything in-between. Enterprises must decide on their position concerning digital sourcing: where do they stand on outsourcing, co-sourcing and insourcing? This is a strategic decision. It relates to the prime value proposition of the enterprise: what unique value does the enterprise offer to the market? And what is needed to deliver this value in terms of competences and capabilities? A complicating factor is that it is increasingly hard for enterprises to define this value on their own. Instead, consumers determine value to an increasing extent [17]. The better the enterprise architecture enables flexible coupling and decoupling of capabilities, the better the enterprise can switch between capabilities and make just-enough, just-in-time use of capabilities offered in the market.

Flexibility in sourcing is an extremely important aspect of modern enterprises, as it determines how fast an enterprise can implement new business models and new manners of collaboration with others. Over the years, the role and conduct of enterprises in the market has changed. Several large companies that traditionally dominated a substantial part of the market got into trouble. Nokia, for instance, dominated a large part of the mobile phone market, but did not realize fast enough that their customers started to rate design above functionality and price. And it lost market share to Apple [17]. We also see that the average lifespan of companies is steadily decreasing [18]. Enterprises that try to do it all on their own are being replaced by enterprises that are open to cooperation with other enterprises [19]. Or enterprises that provide others the platform to cooperate, as is done by the new platform organizations.

The digital business strategies that are the result of rapid technological innovation lead to new value creation models. Pagani distinguishes three types of value networks [19].

The closely vertically integrated model is the classic value chain model. It is designed to centralize organizational intelligence. It is characterized by the presence of a (limited) number of giant components that are strongly connected in a sequential value chain. The driver behind this model is the need to achieve independence and achieve control over the entire value chain.

The loosely coupled coalition model emerged as a response to increasing market complexity because of incremental innovation. Instead of a singular value chain, a value network emerges with various kinds of partnerships between the different parties in the network. Usually some firms achieve more prominence and power by occupying a central position in the value network structure. They use their prominence to grasp a leadership role in pulling together resources. In other words, they take charge of network orchestration. This results in a value chain that is more disintegrated and open. The ability to connect effectively with others becomes a core competence.

The multisided platforms are the result of the emergence of cross-boundary industry disruptions. In contrast to the previous two models, the multisided platform is non-linear. In the multisided platform model, a company brings together two or more distinct groups of participants (sides) that need each other in some way. A multisided platform company builds an infrastructure (platform) that creates value by reducing distribution, transaction and search costs generated when these groups interact with one another. Well-known examples of multisided platform companies are eBay, Visa and Booking.com to name but a few. Multisided platforms can have two, three, four or more sides. The more the sides, the higher the degree of complexity and the greater the challenge of balancing the interests of all sides. The choice of which side to sponsor or not is a fundamental strategic choice. Multisided platforms strive for network effects. Network effect means that the value of a service increases as more consumers use it or more suppliers augment it. In a world of digital and connected services, network effects are the key differentiator and driver of value creation. The multisided platform model may very well penetrate all industries in the near future. And with the multisided platform model new characteristics become important, such as openness, transparency and modularity.

Pagani argues that to survive in an increasingly uncertain and complex environment, organizations must transform their organizational intelligence into a new relational intelligence, enacting an open communication process with their stakeholders. For architecture, this implies a focus on enabling open communication and ensuring a modular structure.

Various factors play a role in catering for the flexible coupling and decoupling of resources or services. One determining factor is the granularity of the components on which the enterprise architecture is built. It is more difficult to outsource only part of a component than it is to outsource an entire component. For instance, if an enterprise has implemented an integrated ERP suite that supports sales, delivery, inventory management, payments and financial administration, it may be hard to outsource just the payments part.

Another factor is the ease with which a component can be extracted from its environment, i.e. how entangled it is with other components. Entanglement can occur horizontally and vertically. Horizontal entanglement means that components of similar nature are entangled. For instance, if the way a process is executed depends on the way another process is executed, or if the working of an application depends on the working of another application. Vertical entanglement means that components of different nature are entangled. For instance, the way a process is executed depends on the way a supporting application is designed. A component that communicates with other components by way of well-defined services can be outsourced easier.

Also relevant is the extent of standardization, especially the standardization of communication. Usually, an outsourced component does not function in isolation but exchanges information with other components. Broadly accepted communication standards enable such exchanges. A component that communicates by means of a widely recognized standard is easier to outsource than a component that communicates in an organization-specific manner. This holds not only for standardization of technical protocols, but, maybe even more importantly, also for semantic standardization. Within an ecosystem of collaborating parties, it is essential for smooth collaboration that participants understand each other. That is why many industry sectors develop common vocabularies, for instance in the water sector (Aquo), the building sector (building information modeling) and the care sector (HL7). Using such standards enables communication in precisely defined terms, making it easier to exchange information without misunderstandings or the need for complex translations, and thus to collaborate.

As technology becomes an important driver, the architecture must be able to absorb new relevant technologies [20]. Thus, the architecture must contain provisions to connect to new digital resources and services. Many organizations have been standardizing on technology for efficiency reasons. For core systems, this may still be a prudent way to go. For continuous delivery of digital services, however, organizations must be able to make use of the newest digital resources, either as a service or as a technology. Adherence to strict standardization rules is not advisable. However, though standardization on technology may hamper innovation, standardization on interfaces stimulates it. Standardization on interfaces enables enterprises to use each other’s services. It stimulates collaboration and interaction. It enables rapid innovation by combining existing building blocks in new ways. While standardization on technology is driven by efficiency, standardization on interfaces is driven by value delivery: it enables seamless interaction of capabilities from different sources to combinedly offer value that none of the collaborating parties could have offered on its own. Thus, a collaboration between Spotify and Uber enables Uber users waiting for their ride to personalize the music during their ride by selecting, via the Uber app, a Spotify playlist to be played during their ride.

Thus, we see that the enterprise architecture enables digital sourcing by (1) incorporating the right form of standardization, (2) defining the right granularity of components and (3) employing a form of service-oriented architecture. However, there is more to the picture. There are a couple of trends that further impact the enterprise architecture management function. These are discussed in the next three paragraphs.

3.6  Enterprise architecture management function

Enterprise architecture provides the organization with the overview and insights necessary to make informed decisions on how to structure its products and services, processes, information flows and technology in a way that is aligned with its ambitions and strategy. The enterprise architecture models provide the required overview and insights. The enterprise architecture principles provide guidance on what to do or not to do when designing changes. The enterprise architecture management function is concerned with effectively applying these models and principles. Effectively applying enterprise architecture models and principles means applying them to provide direction to the change processes of the organization. For it is in these change processes that design decisions are being made, either explicitly or implicitly. Decisions that we want to be informed by enterprise architecture.

Decisions take place at various levels within the organization, ranging from strategic decisions at board level to operational decisions at for instance software development level. Enterprise architecture is relevant to all these levels of decision-making, but in different ways. At board level, the role of the enterprise architecture is to provide overview and to inform management about the impact and consequences of certain choices. Also, we see enterprise architects increasingly take the responsibility to proactively inform management about opportunities, often generated by the architectural choices. At operational level, the role of enterprise architecture is mainly to provide guidance in making specific design choices, either by providing relevant rules or by providing advice on specific solutions [3].

The way the enterprise architecture management function is organized differs between enterprises. Depending on the size of the enterprise, the number of architects may range from one employee fulfilling the role of architect for a part of his/her time to dozens of architects of various types spread over different departments. A common distinction is between enterprise architects who maintain a holistic view over the entire enterprise and solution architects who apply this enterprise architecture to guide the design of specific solutions, for instance a new service to customers. Enterprise architects are usually centrally organized, either as a staff function below board level or as a central team within the IT department. Solution architects may be positioned within or near the development teams. The tasks of enterprise architects consist of keeping the enterprise architecture up to date and in line with the ambitions and strategy of the enterprise, developing roadmaps for realizing target architectures, advising the board about the applicability of technological innovations, implementing governance processes to ensure compliance with the enterprise architecture and educating the organization in enterprise architecture. Solution architects translate the models and principles of the enterprise architecture to specific guidelines for development teams, for instance in a so-called project-start architecture, model the architecture of specific solutions in collaboration with designers, monitor whether design decisions are in line with the architecture and act as advisor to development teams in cross-team issues.

The enterprise architecture management function faces various challenges in the fulfillment of its role. First, there is the question of mandate. Usually, it is not the architect who makes the final decision. In this respect, it is essential that the architects are backed by management. All too often, architects feel forced to sell architecture to the organization as if they themselves are the primary beneficiaries of the enterprise architecture. The main beneficiary of the enterprise architecture should be the board, however. That is why it is important that the enterprise architecture management function reports to the board directly, preferably to the CEO. It is the CEO who should take ownership of the enterprise architecture and who must understand and subscribe all choices made therein. In practice, however, the enterprise architects often report to the IT manager or CIO, limiting their scope to IT. This may restrain their effectiveness in aligning the enterprise architecture with the business strategy.

Effective application of enterprise architecture is also strongly related to its embedding in strategic dialogue as well as in solution development. The enterprise architecture management function must ensure that they can provide relevant insights at the moment of decision-making. Sometimes that may be a vision paper on the applicability of Cloud computing for the organization, other times that may be a specific solution pattern for communication with partners. Sometimes the insights needed can be simply derived from the existing architecture models and principles and sometimes a dedicated deliverable will have to be made. Architectural deliverables must be tuned to the stakeholders of these deliverables and architectural processes must be integrated with the organizations change processes.

The discipline of enterprise architecture is still relatively young. Different organizations show different levels of maturity of the enterprise architecture management function. As a discipline, it is far less established as for instance project management. The demands of digital business strategy and dealing with unpredictability, however, require a high architecture maturity level—especially, because the demands of fast response imply that architects cannot always fallback on premeditated models and visions, but need to “think on their feet” more.

Enterprise architecture maturity models are a means to support organizations in developing their enterprise architecture management function. Maturity models are conceptual models based on the idea that organizational competences develop through a number of anticipated, desired or logical stages from an initial state to a more mature state [31]. More mature means better equipped to fulfill its purpose. The basic components of a maturity model are (i) a number of overall maturity levels, (ii) a number of aspects or areas that can be developed along a predefined evolutionary path to achieve the defined maturity levels and (iii) descriptions of each step on the evolutionary path. In addition, a maturity model may contain suggestions on how to perform the various steps in terms of improvement actions.

Maturity models can be used with three different objectives in mind. First, they can be used to assess the current state of the architecture practices, i.e. how well is the enterprise architecture management function organized and how efficient or effective is it? What are its weak and strong points? Second, maturity models can be used for benchmarking, i.e. to make comparisons between enterprises. Of course, this objective can only be realized if all enterprises use the same maturity model and are willing to share their maturity scores. Third, maturity models can be used to improve the enterprise architecture management function. Dependent on an assessment of the current state, a maturity model may suggest adequate measures to grow to the next maturity level.

An example of a maturity model is the model developed by Ross et al. [32]. They discuss four stages that an organization passes through, making increasingly effective use of enterprise architecture: (1) business silo (IT applied to specific business needs, locally optimal business solutions), (2) standardized technology (central technology infrastructure), (3) rationalized processes (base of IT-enabled processes for core operations, shared and standardized business processes and/or data) and (4) business modularity (building on the core processes with plug-and-play processes built internally or externally). As an organization moves up through the stages, the strategic impact of IT increases. The organizational changes at each stage include new business processes, new management practices, new governance approaches and new attitudes about the role of IT. Ross et al. found in their research that large firms required on average five years per stage. They issue a warning that it is not possible to skip a stage. Each stage involves technology and organizational changes that prepare for the next stage. As the term suggests, to fully support a digital business strategy seems to require the stage of business modularity. Some organizations, however, are still struggling to get their operational backbone up and running, i.e. to reach the stage of rationalized processes. This is a serious threat to their business success. The maturity model of Ross et al. is primarily useful for assessing the current state of the architecture practices.

Another type of maturity model is the Dynamic Architecture Maturity Model, DyAMM, which is part of DYA [33]. DyAMM is designed and used for all three objectives mentioned above. It could be used to grow to level four of Ross et al. The DyAMM model distinguishes 17 aspects, called focus areas that together comprise an enterprise architecture practice. The focus areas are the development of architecture, use of architecture, alignment with business strategy, alignment with realization, relationship to the As-Is state, responsibilities and authorities, alignment with change portfolio, monitoring, quality assurance, management of the architectural process, management of the architectural products, commitment and motivation, implementation of the architectural role, architectural method, interaction and collaboration, architectural tools, budgeting and planning. The aim of DyAMM is to assist enterprises in increasing their enterprise architecture maturity step by step by developing each of the focus areas in a balanced manner. The idea behind DyAMM is that though each of the 17 focus areas must receive attention, this does not mean that each must be given equal consideration at the same time. For instance, not every focus area is equally relevant at the start: the use of architectural tools will certainly become a key concern at some point, but enterprises that are still in the phase of building up an architectural practice can focus more productively on aligning the architecture with the business strategy. Tools will have their turn. Furthermore, any given focus area need not be brought up to its full state of development right away. Each focus area has its own levels of maturity and the DyAMM model provides a matrix that shows how to alternately develop the different focus areas level by level. DyAMM distinguishes 12 overall maturity scales. For most enterprises, however, scale 6 will be more than adequate. Enterprises with a complex product portfolio and corresponding complex organization may aspire to scale 8 or even 10.

There is not one best way to organize the enterprise architecture management function. Its effectiveness very much depends on whether its implementation matches the size and organization of the enterprise. However, a maturity model such as the DyAMM model provides a useful tool to assess and subsequently develop the enterprise architecture management function to the required level.

3.7  Conclusion

The aim of enterprise architecture is to provide the structure to an enterprise that matches its strategic ambitions and enables the enterprise to turn strategy into execution. It does so from a holistic perspective, aiming for the seamless connection of products and services, processes, information flows and technology. The discipline of enterprise architecture consists of both the enterprise architecture artifacts, distinguishable into models and principles, and the enterprise architecture management function of developing and applying the enterprise architecture artifacts.

Digital sourcing in today’s world puts certain requirements on enterprise architecture. Above all, it asks for the flexibility to quickly respond to changes in the environment and to flexibly start and end collaborations with other parties.

The enterprise architecture is an important enabler of digital sourcing by applying a service-oriented approach, modeling independent business capabilities at the right level of granularity, standardizing on interfacing instead of technology and formulating architectural principles from an outside-in, customer-centric perspective. The balance between robustness and flexibility can be supported by varying the level of normative statements using principles on one occasion and rules on another.

To be effective, the enterprise architecture management function must be aligned with the change processes in the organization, at all levels from strategic to operational, to be able to provide to-the-point advice at the moment of decision-making. This implies that the enterprise architecture management function tunes itself to the change processes in which the design decisions are made. In this effort, maturity models may function as useful checklists.