Is DevOps making Enterprise Architecture obsolete?

by Max Körbächer / May 25th 2018

Based on Agile and DevOps principles, many IT functions are moving towards an organization that consists of small, autonomous teams. By doing so they hope to simplify decision-making, ensure end-to-end responsibility, increase business-IT-alignment, and speed up development. Given this trend, you may ask if there is still a need for a central Enterprise Architecture (EA) function. And if so, how does it need to adapt?

At ProSiebenSat.1, we believe that EA is needed now more than ever. As teams become more autonomous, it is becoming increasingly more important that there are ground rules that allow teams to collaborate easily and people to move across teams. In addition, there is also an increasing need for organizing the knowledge exchange among architects as we move away from a functional organizational structure.

With this in mind we have defined eight core tasks for our EA function:

  1. Define architectural principles
  2. Classify technologies and define a technology roadmap
  3. Support application lifecycle management
  4. Create an architectural single point of truth
  5. Define target architecture
  6. Automate information gathering
  7. Run an architecture community
  8. Support complex architectural projects

Define architectural principles

EA is the framework in which our solution architects can act freely. Our first step was defining our nine architectural principles with the aim of building a common understanding of how we want our architecture to be structured and to provide a kind of checklist to be taken into consideration during the solution design.

  1. Single source of truth: One system that is accountable for one or more business objects, that others can use but not change
  2. Modular design: For example, architectures based on domain-driven design or microservice approaches
  3. Explicit interface contracts: Clean and clear interfaces and dependencies
  4. Resilient system architecture: A system that is independent from other systems’ faults, errors, and outages but also resilient against internal issues
  5. Economic efficiency: Efficient cost-to-value ratio
  6. Security by design: Applications are to be built securely by default, following our security guides
  7. Avoid technical dependencies: Applications are to be exchangeable and operational, not dependent on one another
  8. Architectural transparency: Architecture must be visible, understandable, and documented to enable other architects to participate in or to learn from it
  9. Avoid unnecessary complexity: Evolve the architecture in a highly cohesive manner and ensure loose coupling so that parts of the application are not restricted

Classify technologies and define a technology roadmap

Another pillar of our architectural framework is a technology catalog (see below) which classifies whether items such as operating systems, databases, web servers, and programming languages are strategic, restricted, or prohibited. Standard technology can be used whenever needed. Restricted technologies would require a specific reason for use. This classification is also used to identify which technologies can be observed or tested should the occasion arise. Prohibited technologies will be phased out gradually as they may still currently be in use or their use will no longer be permitted in the future. In addition to this we will collate information from projects and architects about technologies that work – or don’t work – so that we can share this knowledge within the organization. This bundle of information is what we call our technology roadmap. However, defining the technology roadmap in this way alone does not take into account future developments and progression. Thus, we also analyze market trends in technologies and techniques and assess capabilities offered by potential vendors. Combining the aspects of what we are good at and what we know with where we estimate the market is going, and what suits us – this is how we create a comprehensive technology roadmap.

Tech Road map

Support application lifecycle management

As EA we actively support application lifecycle management. The application lifecycle starts when an application is in development or production, monitors the application’s status and determines when an architectural review is required, defines the appropriate time to action changes to ensure the solution is fit and healthy for the future, and then finally determines when it is time to say goodbye to that particular application. Monitoring an application over its lifetime helps to identify early risks and problems, and allows us to intercept these negative changes early on. Another indicator of early risks is the vendor support dates for each technology which are managed in our EAM tool, which refer to specific applications.

Create an architectural single point of truth

To see the bigger picture, all the dependencies, and how strategy is realized, you need an instrument for measuring and documenting. In the early days of EAM we used quite an inflexible and not particularly user-friendly tool; this is why we introduced iServer as our future Enterprise Architecture Management (EAM) system. It allows us to query information delivered by solution owners and architects so that it’s measurable and visible. Additionally, Visio integration allows synchronization between iServer and Visio objects. So, changes in iServer will be shown in the diagrams, while changes in the diagram will also take place in iServer. For architectural and further information about applications we also use iServer as our single point of application architecture documentation. One of the key reasons for this was that we could quickly answer questions about any given application. This type of Adhoc Request could happen during a meeting or workshop, and typically covers questions such as: What does this application do? Where does the data base run on? What dependencies does it have? Our online portal means we can quickly and easily search for the required information and then send it in link form to the meeting or workshop participants. In addition to this we can also easily define clients’ more complex queries in our iServer and then make them accessible for others, e.g. as an Excel file or a PDF download. The image below gives an indication of what it looks like.

iServer

Define target architecture

With the information we gather via our EAM tool we are able to paint a clear picture of our current AS-IS architecture, also called the architecture landscape. Combining this information with other details such as business capability maps, deployment diagrams, and information flow diagrams, we are able to see an overarching view of if/where we are over- or under-committed within the architecture. This gives us the opportunity to plan the evolution of our architectural landscape and design our ideal architecture. Further input from businesses and our own technology roadmap enables us to focus on creating the most suitable architecture for us. However, the difficult part nowadays, with DevOps and microservices, is that architecture projects quickly adopt new components and shapes. But this can be taken into consideration during the planning and evolution of the architecture.

Automate information gathering

As you can imagine, we are highly reliant upon the quality and quantity of information we receive from the various users. For this reason, we aim to keep our Enterprise Architecture Methodology as lean and flexible as possible, as the biggest challenge in enterprise architecture management is reaching a high level of data quality. This subject is set to get even more complex in the future. Deploying a dockerized application up to a hundred times a week also means changes to the technologies used and the interfaces between the microservices. To face this challenge, we are currently working on the automation of our data delivery via system management, license management, and discovery tools. This deep integration should help us to stay up-to-date while at the same time reducing the effort required from the solution owner.

Networking ProSiebenSat.1 Tech Run an architecture community

Each department – whether it’s media solutions, sales, or broadcasting technology – has at least one solution architect. This allows us to have autonomous teams who can make decisions independently. To ensure that these decisions align with our overall target, we established an architecture community. The architecture community is a platform which allows all architects from all departments to present their topics to each other on a regular basis. This has resulted in the conjoining of bottom-up and top-down topics, and all of those involved in architecture are able to discuss these matters freely among themselves.

Support complex architectural projects

One of the easiest ways to better understand your organization is to take an active role in its projects. This could be, for example, leading the overall architecture of a large transformation program, defining the target architecture of a project, or working hands-on to build cutting-edge technology such as a container orchestration platform. But the key factor to success is close collaboration with our solution architects, to be the solution architect if needed, and to serve and guide our scrum teams.

Roll up your sleeves and get going

So, to answer our initial question: No, DevOps doesn't make EA obsolete. EA is still absolutely required for the future handling of these complex modern systems as well as to guide our agile and independent teams. However, the role of an enterprise architect will need to change; there is no room in this culture for someone to stand in their ivory tower, screaming paradigms to all and sundry. Enterprise architects will need to adopt this new culture to become a valued and valuable member of it.

MORE BLOG POSTS