BONN – Monday, January 15, 2018
What enterprise architects need to be able to do
Enterprise architecture is changing fundamentally under the pressure of digitalization. It is developing a new understanding of itself and expanding its scope of activities. This development is also changing the requirements software architects need to meet, as a survey of major corporations such as Daimler, Deutsche Bahn, and SBB (Switzerland) has revealed.
Twenty years ago, enterprise architecture management was above all an instrument for harmonizing and consolidating IT landscapes. These days, flexible architectures are developed that can accelerate the digital transformation in business organizations by integrating technical innovations and the rapid changes made to business and work processes.
This can only work, however, if procedures and work methods can be adapted, whereby the idea here is to move away from stipulation, monitoring, documenting, and controlling toward a system marked by active support for innovation, as well as the provision of advice. This in turn will result in the formulation of architectural guidelines that are understood and followed by employees, whose compliance therefore doesn’t need to be constantly monitored.
This modified understanding of the role of enterprise architecture, coupled with the use of new approaches, is now beginning to change the nature of architectural expertise and is also leading to the establishment of new work methods and processes. With all of this in mind, we asked enterprise architects at our member companies some questions about the changes enterprise architecture is undergoing, and the new requirements architects now face as a result.
The changed role of enterprise architecture at Daimler
Wilfried Reimann, Head of Architecture and Innovation at Daimler AG, describes the role formerly played by enterprise architecture (EA) at his company as follows: “In the past, we worked on creating an optimal system landscape for a stable company. EA – and this was the case at other companies as well – was based on a minimalist approach; in other words, only things that were absolutely necessary were permitted. This isn’t exactly the best method for moving into new fields in a rapid and agile manner.”
Reimann believes that the increasing importance of enterprise architecture can be attributed to the much greater importance of IT today, as IT is now once again playing a crucial role at many companies as a result of the digital transformation. “These days, added value is mainly generated by software and the services they enable,” says Reimann. “This puts more pressure on IT to create these value-generation possibilities and to speed things up in general.
At the same time, one should not ignore the changes taking place in the existing IT landscape. In order to be able to quickly change an existing IT landscape, you also have to be able to quickly adapt the core system. Increasing complexity needs to be reduced over and over again, while interfaces need to be kept simple, and there shouldn’t be too many differences between them either.”
Reimann is optimistic about the future of EA. “Whereas the idea in the past was to limit the complexity and costs of IT landscapes, the goal of EA today is to maintain each system’s ability to change,” he explains. This in turn requires that architects make extensive use of innovations, promote change, maintain a clear overview, and are able to utilize existing systems effectively.
A controlling background is no longer part of the job description for enterprise architects
Daimler plans to significantly increase IT vertical integration in order to speed up IT operations. “We plan to hire a lot more software developers and people with technical skills who can create their own applications,” says Reimann. This also applies to architects, since they will be part of development teams in the future. According to Reimann, EA experts need to be skilled in the innovative disciplines. They also need to build systems themselves and will have to be able to work with the new types of teams that will be created.
Reimann would therefore like to see architects who are also very good cloud architects, and who can parallelize applications and enjoy working in DevOps environments – i.e. “people who are more technically oriented.” These architects will in fact need such technical expertise, and a certain amount of corresponding experience, if they wish to be taken seriously. They will also need to have very good communication and facilitation skills. At the same time, rhetorical skills alone are not enough for an architect today, and other aspects have changed as well: “In the past, someone with a controlling background could also become an architect, but that’s no longer possible today,” says Reimann.
Architects are increasingly becoming facilitators as well
Another enterprise architect executive at a very big German industrial company emphasizes how important it is for architects to have good facilitation and communication skills. “We bring many different groups of people together and make sure they get the assistance they need,” says this enterprise architect, who wishes to remain anonymous. Although she believes it’s very important for architects to be specialists in their field, she also says that “we always want architects to have general skills as well.”
Architects build bridges between software development and specialist and technical departments, which is why it’s important that they quickly develop skills relating to facilitation, communication, conflict resolution, and mediation. In a process similar to that which is occurring at Daimler, this architect’s company is also developing a new training concept and even a new specialized career path for architects.
In this company as well, EA is becoming more important as a result of digitalization, as the architect explains: “Everyone sees that digitalization only works if you have a solid IT system that can be expanded and modernized, and which also probably has to be structured differently than in the past. This is causing a run on IT departments, so to speak, and the specialist and technical departments are also discovering that in some cases their requirements overlap, conflict with one another, or have already been formulated by other departments. They have therefore come to understand that there needs to be some kind of authority that is able to keep an eye on the overall system and its efficiency, despite all of the different requirements. EAM can act as this authority because it has the knowledge and tools needed to play that role.”
Customer focus conflicts with the old EA rules
According to our architect, the numerous new requirements, which are also dramatically changing the way enterprise architects are trained, as well as the nature of their work, all come down to one thing: customer focus. “This of course is causing us to take a second look at the rules used with traditional EA, which focuses on eliminating redundancies, harmonizing systems, and establishing uniform company-wide standards,” the architect explains. “End customers aren’t interested in any of this; they just want to have a fast application that’s easy to understand and is also fun to use.”
This situation has led to new work methods for EA: “We no longer wish to work with top-down rules and provisions. Instead we want to offer services that a large number of people view as helpful. What we want to achieve is something like a ‘soft’ standardization effect. Here, standards are no longer stipulated but are instead so attractive that everyone wants to adopt them and use them.” This new mindset is having an effect on cooperation with EA organizations and it basically guarantees that “we neither end up in an ivory tower, nor are we viewed as an organization that inhibits development.”
Enterprise architects at DB Systel: Less control, more cooperation
Stefan Gerberding, an enterprise architect at DB Systel, reports that Deutsche Bahn launched a digitalization program known as “Railway of the Future” last year. “The restructuring of the IT landscape is part of this program, and enterprise architecture is one of its key components,” Gerberding explains.
Between 150 and 200 architects are currently working at DB Systel alone, with 30 of them directly involved in enterprise architecture. One team here supports the CIO with internal IT planning, while another works with DB Systel’s CTO. The latter team performs architecture tasks in all different areas, develops reference architectures, addresses IT governance issues, and analyzes technology trends.
DB Systel hires architects who have a degree in a technical field and several years of experience as a software developer and/or project manager. Architects at DB Systel also need to have good communication skills, including the ability to communicate effectively with C-Level executives. Gerberding describes the ideal attributes of an architect as follows: "goal-oriented, structured, open to new ideas, and willing and able to learn, communicate, and deal with criticism.”
He believes it’s important for architects to have extensive knowledge of software architecture and experience working as an architect in (major) IT projects. “I also think it’s important that architects are aware of which architectures have proved their worth in practical applications.” Gerberding says that while it’s helpful if software architects have project management experience, such experience is a must for enterprise architects.
He also agrees that work methods are changing in many ways. For one thing, the required skill set is getting bigger because architects now need to know how to include in the developed software certain properties that used to be implemented by data center infrastructure units. “Back then, architects didn’t need to worry about high availability or network security,” Gerberding explains. “In the public cloud, which is what we’re going to be developing many of our systems for in the future, architects need to think about the best way to achieve high availability and network security, for example.” Gerberding also points out that architecture approaches are moving away from the waterfall model and toward an agile model. “Architects need to get used to new circumstances,” he explains. “In some cases, they will now work on new architectures with their development colleagues in DevOps teams.”
Gerberding says that enterprise architecture organizations in general will focus less on controlling and more on development cooperation with other organizations in the future. He also believes that architecture knowledge and awareness in IT departments of the importance of this knowledge will increase significantly, which in turn will decrease the need for central governance.
“Naturally, there will still be guidelines and we will play a very active role in sensitive areas especially – for example those relating to security,” he explains. “However, the strong focus on governance of the overall system will disappear, not least due to the fact that the associated approaches have proved to be excessively slow in the digital world. Our goal is to give teams a lot more responsibility and ensure they have sufficient architecture expertise and are aware of the importance of architecture for the whole company.”
SBB in Switzerland: Strict governance inhibits agile development
Yannis Baillet, an enterprise architect at the Swiss railway company SBB, says the conditions in which EA organizations operate are changing at his company as well. For example, it seems that at some point system stability and the elimination of redundancies were suddenly no longer the most important criteria for IT. Instead, these had been replaced by agility and flexibility. “In such a situation, strict governance that extends across the entire IT landscape tends to inhibit progress,” Baillet explains.
However, because SBB’s architects very quickly began to look for ways to accommodate the demand for greater agility, EAM was never really called into question as a discipline. On the contrary, because IT was given the task of managing the digitalization process (with the “old” architecture team assigned a leading role here), it now turns out that EAM is viewed as being very important at SBB today. “These days there’s not much interest in the traditional role of architecture as a governance function,” says Baillet, adding that he believes this is mainly due to the increasing use of agile development principles. The traditional enterprise architecture plan, with its defined development steps and central gateways, no longer works here. Indeed, in agile environments, responsibility for architecture is spread out among the teams, whereby this also includes – at least in part – responsibility for the technology used and for ensuring its smooth operation.
Then there’s the fact that the use of tools and technologies is much more “unstable” today than it was in the past: “Developers try out certain tools and maybe work with them for a short time – but as soon as something better comes along, they start using that instead,” Baillet explains. “It’s no longer possible to limit everyone’s activities to the use of certain methods and tools. Everything is moving too fast for that now.”
That’s why the architecture team at SBB now focuses more on consulting rather than trying to stipulate the use of certain processes, systems, etc. “We want to help make projects more successful,” is how Baillet describes the new approach. These days, only those projects deemed to be extremely relevant go through an architecture gate, whereby relevance is assessed on the basis of strategic importance, the budgetary framework, and potential risks. The architecture gate itself has also been changed – it’s no longer a hard gate but instead represents a type of support and advice process. “You can look at it as something like having an embedded architect,” Baillet explains. “Here, architects and project teams work together from the very beginning and discuss requirements critical to architecture, whereby the architects help the project team meet the requirements, or else they suggest alternatives. This approach can also lead to architects working directly in project teams.”
And what does SBB expect from its architects? SBB architects’ education and training backgrounds tend to differ greatly, but the basic requirements at SBB are similar to those at the other companies examined in the survey. For example, architects at SBB need to have a university degree and experience as a software developer or architect. Baillet will also consider candidates with a business background, provided they display a true interest in and have extensive knowledge of IT systems. SBB architects also need to have extensive general technical knowledge and strong communication and consulting skills.
New EA can also be placed under the control of the CDO or CEO
Beyond the views of the enterprise architects cited here, the Cross-Business-Architecture Lab also assumes that enterprise architects will need to possess more domain knowledge and business expertise in the future in order to successfully address the challenges their companies will face as the digital transformation continues.
“New enterprise architecture no longer has to be an exclusive CIO discipline; it can also be a corporate discipline whose activities fall under the responsibility of the CDO, COO, or CEO,” says Karsten Schweichhart, Member of the Board of the Cross-Business-Architecture Lab, an association in which major companies address issues relating to enterprise architecture and digital transformation.
Speed, flexibility, and interoperability will be the critical factors of architecture-management success in the future. As Schweichhart points out, this means that enterprise architecture needs to be much more closely linked to other specialized planning processes in the value-creation network - e.g. production, sales, marketing, innovation, and digitalization planning. However, EA has to be a planning partner on an equal footing here, rather than just an organization that collects the requirements of other planners and then develops approaches for meeting them.