News

9/20/2018

A total of 70 percent of our work today consists of making change possible

We spoke with Dr. Thomas Greutmann, Head of Enterprise Architecture at Otto and a speaker at our conference “EAM – Pointing the Way Forward for the Digital Transformation,” about the new role architecture now plays and how he and his team are making it possible to implement changes at Otto quickly, while at the same time maintaining a networked and well functioning IT landscape.

What’s going on with enterprise architecture today?

It seems to me at the moment that IT, and especially architecture, are splitting up into two groups. Up until a few years ago, architects were mainly the ones who focused on implementing the efficiency and optimization agenda at the companies where they worked. Technology was used primarily to optimize the existing business. A lot of new technologies and innovations were employed here, like CRM, BI, etc. However, again, the goal was always to improve the existing business. For a company like Otto, which is a retailer, the use of new technologies made it a better retailer. Now, however, a paradigm change has occurred at some companies. These companies no longer use technology only to improve their business but also to change their business model. For example, automakers today don’t just think about manufacturing cars; they also think about marketing mobility.

Has such a paradigm change taken place at Otto as well?

We are transforming Otto from a purely retail operation into a platform business. We want to remain a retailer, but we also want to make it possible for other companies to conduct their retail business online. This involves a completely different business model, which means that the way we define good IT and architecture has also changed completely.

Up until three years ago, efficiency, IT management, and architecture management were very important to us. We did a lot of monitoring, managing, and optimizing – but now it’s all about the speed of change. Being efficient is not enough to win in our market – we can only win if we are able to change rapidly.

This realization led us to conclude that we had to be able to change much more rapidly than ever before. With regard to architecture in particular, we had to completely restructure ourselves in terms of our organization and the technology we use. As an architect, I had to start viewing things as wrong that I had previously long viewed as right. Reusability – in other words having one system perform one function to the extent that this is possible – used to be considered good architecture. These days I need to allow redundancies to exist if I want to be fast. In other words, the entire value system relating to what constitutes good IT and good IT management has been turned on its head.

Are you saying that architecture has changed extensively in order to enable more changes to be made more rapidly?

Yes – because the primary goal is no longer efficiency but instead the ability to change quickly.

Here’s perhaps a dumb question: Does what you’re talking about still constitute enterprise architecture?

Yes, but we’re doing it differently now. In the past, our approach focused very strongly on planning. We defined a target and a roadmap to go with it and then spent five years implementing it. That approach was entirely okay up until two or three years ago. These days we utilize an incremental bottom-up approach. We focus on certain topics and we have teams that address them. We as architects work on an equal footing with these teams, which ultimately develop innovations that we make sure can be used with one another effectively. However, we no longer develop major plans that others implement and which we “defend” with governance measures. We support the teams and ensure the appropriate networks are in place. The interesting thing here is that this new interpretation of architecture has made us more appreciated throughout the entire organization. Our former governance function was extremely unpopular because everyone wanted their project to go through, but they had to pass through us first to get approval. That setup no longer exists. We work more closely with the organization and the teams, whereby all of us focus together on the major changes that need to be made. We also used to get bogged down in a lot of details, but 70 percent of our work today consists of making change possible.

How did the architecture team at Otto feel about the changes made to its own approach? Was the paradigm change ordered from above?

No one told us that we shouldn’t be performing governance functions anymore, or that we should stop planning. In some cases at least, we were the ones who defined the new tasks we were to perform. We were definitely helped here by the fact that two-thirds of our backend IT organization had already changed considerably. The backend, which constitutes around half of the entire IT organization, was restructured from a traditional functional organization with business analysts, developers, testers, and business management staff into a a cross-functional, professionally divisionalized organization. As a result, IT was organized on the basis of business services and there were no more projects, which also meant we no longer had any possibility to establish a traditional governance system. This in turn meant that we had to think of something new. Here, we as a team focused very strongly on the change to the overall business model that Otto was seeking to achieve. There wasn’t any big master plan, however.

In most cases, a master plan that the entire development process follows can only be designed after the fact, but nearly everything you do every day occurs step by step – and not always with the big goal in mind while you’re doing it. It’s only afterwards that everything seems to make sense, and after a year you realize that everything works very well and that you’re operating in a whole different universe, so to speak.

We realized that our environment was changing significantly and we asked ourselves how we needed to structure our organization in this new environment. We were very deliberate in our approach here and we discussed this issue in teams. This ultimately led to the adoption of a bottom-up approach for our structure.

You refer to bottom up as if it were a matter of course, but up until recently such an approach was completely foreign to the philosophy of traditional enterprise architecture.

That’s correct in terms of traditional architecture.

Are you saying that everything associated with traditional architecture has now disappeared?

No, a lot has changed but certain approaches, such as permanent storage in a repository or, to put it another way, storage in an IT registry, also help us with the new forms of work that we now use. Having precise knowledge of the entire landscape with all of its branches and interfaces, and understanding how the different elements interact with one another – that’s still a big help to us. When addressing major cross-sector issues, such as the recently implemented EU General Data Protection Regulation, it’s important to know how many business assets, properties, products, etc. you have that are relevant in terms of data protection, and where these are located. This was a tremendous help in getting measures associated with the GDPR off to a very quick start. We were also able to exploit this knowledge to our advantage when we relocated our data centers. For example, we were able to very quickly determine which applications would be affected and which would have to be moved. The registry system also helps us manage change in the sense of obtaining a clear picture of our starting position and developing an initial iteration of the vision we’re looking to achieve. At the same time, we no longer work with big defined plans; it’s more like we operate in a sketch mode, just like building architects do sometimes when they use pencil sketches to figure out exactly what they’ll need for the actual job. We put together such sketches very often. Others aren’t as good as we are when it comes to painting a big picture that shows everyone all the various relationships and interconnections.

Take platform development, for example. We had five or six iterations or drawings that then served as a basis for architects and the teams to jointly produce a sketch that showed why platforms are important for our technology.

After long discussions with the various teams and responsible managers, we concluded that we needed to rebuild several key components of our ERP system. However, it wasn’t the architects alone who came to this conclusion, and it would be arrogant for us to claim that we are the drivers of innovation. Instead, this idea was developed jointly by the entire technology organization in a long and sometimes difficult process. That’s an example of innovation from the bottom-up. We have to let people develop ideas and we need to help them make their ideas dockable. This requires us to actively participate in the innovation process and repeatedly produce new sketches showing how the new big picture might be structured. This is one of the tasks that we’re focusing on at the moment. We don’t invent things alone; it’s more like swarm intelligence.

I also believe that change is too complex to be managed successfully from the top down.

What do you mean when you say “dockable?” Do you mean that the different systems can continue to communicate with one another even if they have been changed or switched?

This has less to do with the technical side of things and a lot more to do with what the technology actually does. More specifically, we make sure that domains and products can exchange information. We want to stay away from the technical side of things as much as possible because we don’t design the technical systems. This is also why we don’t guard technology standards.

Could you give me an example of functional communication in a business process?

We recently addressed the issue of the communication of requests and orders with partners. Two technical teams wanted to establish sub-processes here, so we got together with the teams to determine whether the activities matched up, or if not, how we could adjust them so that they would both serve the aims of the overall process. To this end, we drew up a partial picture with the teams in order to point them in the right direction in terms of bringing these sub-processes together. That doesn’t end the sketching process, however, since we also have to ask ourselves if we’ve taken all loose ends into account. As it turns out, this is usually not the case – until at some point we make sure it is. Our job as architects is also to ensure that someone handles the other sub-processes, such as those for invoicing, complaints, etc. Metaphorically speaking, we make sure that there’s not only someone who produces plugs, but also someone else who makes the sockets available. That’s how we address and tie up the loose ends.

That’s a much more modest approach than that used with traditional enterprise architecture, which made rules and insisted on having a governance system to monitor compliance with those rules.

Governance has changed a lot as well. At Otto, we not only changed this functional step in order to align it more closely with our features; we have also taken measures to ensure operational teams are given a lot more responsibility. If these measures are understood and accepted, then people will in fact take on more responsibility, and in doing so will ensure that useful things are done where they’re needed. If you get other people to check up on them, however, you send a message of fundamental distrust. We need to move away from that and toward a culture of basic trust. We’ve accomplished a lot in this regard, and such achievements are necessary to ensure that an approach like the one we’re now employing at Otto can succeed. Governance is more like a veto power for us today, and that’s a lot different than approval power. In the event of any doubts, the burden of proof now lies with the architecture organization and not with the technical team, as used to be the case.

Does the registry system you mentioned ensure the transparency of the new approach?

It ensures transparency on the one hand, and it also ensures – and this surprised a lot of people – that we are always able to quickly depict our IT landscape from new and different perspectives.

Does the repository also support inventory operations and thus enable you to determine whether new services are actually needed, or if instead the functionality they offer already exists somewhere else?

Yes, it does that as well, of course, and that also makes us faster. However, the important aspect involves the other way we use the registry. Again metaphorically speaking, we also use the registry to help get a new airplane off the ground rather than trying to prevent it from being designed simply because it might make an existing plane superfluous. Obviously, sometimes things that make no sense have to be prevented. That may be unpopular but it’s also very helpful and beneficial. Still, the main task of “new” architecture is to enable change and help create new things.

Even if you don’t know what the ultimate goal is.

Yes, because in most cases there is none. Urban planning offers a good example of this. Most cities were not planned in advance. When Hamburg came into being back in the eighth century, no one had a sketch that showed what it was ultimately supposed to look like. Urban planners today tend to ask themselves how they can further develop a city and ensure that new residents can be absorbed safely and comfortably. To this end, they sometimes utilize and optimize existing infrastructures or expand them, or else they design completely new neighborhoods, like HafenCity in Hamburg. The work we do is similar in this regard. We’re in a deep change mode at the moment, and to keep with the analogy you could say that the entire company is currently building its own HafenCity.

Does enterprise architecture always oscillate between an optimization mode and a change mode? Or do these modes sometimes occur simultaneously?

We have in fact shifted to another paradigm – from an efficiency paradigm to a change paradigm. Sometimes I wonder if we will shift back at some point, or if we’ll remain in the change mode. I honestly don’t know what will happen, but I can’t see us going back to the efficiency mode in the foreseeable future.

Security and cost control were also two central tasks of traditional architecture. How does the new architecture address these issues?

We have our own security team outside of the enterprise architecture group. However, this team focuses more on training and enabling than on monitoring. We utilize a concept known as the security belt, for example. It’s like judo – the more experience and skills you develop, the higher your security ranking. What’s more, only those who have attained a certain color belt – in other words a certain level of security prowess – can use the cloud. Of course, all members of the team also conduct hard penetration tests and the like, but you need to be able to deal with people differently in the cloud – you need to have certain skills and a certain awareness.

Does top management have specific expectations regarding what enterprise architecture should accomplish?

Our CIO is also the member of the Executive Board with responsibility for technology, which makes it clear just how important technology is at our company. We as architects are not that visible on the top management level, however. We are much more visible on the level of the stakeholders who actually use the systems, which I also think is more important. We exchange ideas and information with them on an ongoing basis. Nevertheless, I am always aware of the issues top management is addressing at any given time. This is important because we need to be aware of the context in which we’re operating if we’re going to be successful as architects. We’re also lucky that we had a reorganization that made us part of the Otto brand and no longer part of the Otto Group. This has brought us much closer to the operating business, and that’s been a big help to us.

Zurück