How agile Enterprise Architecture builds agile business advantage

The next BriefingsDirect digital business trends discussion explores how Enterprise Architecture (EA) defines and supports more agile business methods and outcomes.

We will now learn how Enterprise Architects embrace agile approaches to build competitive advantages for enterprises and governments, as well as to keep those organizations more secure and compliant.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.

To learn more about attaining agility by the latest EA approaches, we are now joined by our panel, Mats Gejnevall, Enterprise Architect at minnovate and Member of The Open Group Agile Architecture Work Group; Sonia Gonzalez, Forum Director of the Architecture Forum at The Open Group; Walters Obenson, Director of the Agile Architecture Framework at The Open Group, and ?ukasz Wrze?niewski, Enterprise Architect and Agile Transformation Consultant. The panel is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Gardner: Mats, what trends are driving the choice and motivation behind a career in EA? What are some of the motivations these days that are driving people into this very important role?

Gejnevall: Most people are going into EA because they want to have a holistic view of the problem at hand. I do think that EA is a mindset that you can use to apply to any type of issue or problem you have. You look at an issue from many different perspectives and try to understand the fit between the issue or the problem and potential solutions.

That’s human nature to want to do, to look at things from a holistic point of view. It’s such an interesting area to be in, because you can apply it to just about everything. Particularly, a general EA application, where you look at the business, how it works, and how that will affect the IT part of it. So looking at that holistic view I think is the important part -- and that’s the motivation.

Gardner: ?ukasz, why do you think agility particularly is well addressed by EA?

Wrze?niewski: I agree with Mats that EA provides a holistic view to understand how organizations work and can enable agility. As one of the main enablers for agility, EA changes the organization in terms of value. Nowadays agility is the trend, the new way of working and how the organization transforms itself for scaling the enterprise. EA is one of the critical success factors. 

EA’s holistic point of view

Gardner: It’s one thing to be a member of this noble profession; it’s another for organizations to use them well. 

Mats, how should organizations leverage architects to better sustain an agile approach and environment? It takes a receptive culture. How do organizations need to adjust?

Gejnevall: First of all, we need to distinguish between being agile doing EA and EA supporting an Agile approach. They are two very different things. 

Let’s discuss being agile doing EA. To create a true agile EA, the whole organization needs to be agile, it’s not just the IT part. EA needs to be agile and loosely coupled, one of the key concepts, applied both to the business and the IT side. 

But to become agile doing EA, means adopting the agile mindset, too. We talked earlier about EA being the mindset. Agile is also a mindset – how you think about things, how to do things in different ways than you have been doing before, and to look at all the different agile practices out there. 

For instance, you have sprints, iterations, demos, and these kinds of things. You need to take them into your EA way of working and create an agile way of working. You also need to connect your EA with the solution development in agile ways. So EA and solution development in an agile way needs to connect in the long-term.

Gardner: Mats, it sounds a little bit like the chicken and the egg. Which comes first, the EA or the agile environment? Where do you begin?

Change your mind for enterprise agility

Wrze?niewski: Everything is about achieving the agility in the enterprise. It’s not about doing the architecture. Doing the architecture in an agile way is the one thing, but our main goal is to achieve enterprise agility. EA is just a means to do that. So we can do the architecture in a really agile way. We can do the sprints, iterations, and apply the different agile methodologies to deliver architecture. 

But also, we can do architecture in more traditional way, the understanding of how a system is complex and how to transform the system in a proper way, the organization as a system, and we can achieve agility. 

That’s a very important factor when it comes to people’s mentality and how the people work in the organization. That’s a very big challenge to an organization, to change the way of working, to change the mindset, and really the Enterprise Architect has to sometimes take the shoes of the psychologist.

Gonzalez: Like ?ukasz said, it’s the mindset and to change your mind. At first, organizations need to be agile based on Agile principles, such as delivering value frequently and aligning with the business strategy. And when you do that, you also have to change your EA capability to become more agile, starting with the process and the way that you do EA. 

For example, using sprints, like ?ukasz said, and also to be aware of how EA governance can support agile. As you know, it’s important to deliver value frequently, but it has to be aligned with the organization view and strategy, like Mats said at the beginning, to have the overall view of the organization, but also to be aware, to handle risk, and also addressing compliance. You may go through an agile effort without considering the whole enterprise, and you are facing the risk of different teams doing things in an agile way, but not connected to each other.

It’s a change of mindset that will automatically make you change the way you are doing EA.

Value stream helps express the value that an organization produces for its stakeholders, the outcomes it produces, and the different stages needed to produce that value. It provides a concept that's less detailed than looking at your individual business processes. 

Gejnevall: As ?ukasz was saying, I think it’s very much connected to the entire organization becoming agile. It’s a challenge. If you want to do EA for an agile organization, that’s something that probably needs to be done. You need to plan, but also open up the change process so it can change in a correct and slower way, because you can’t just come at it top-down, to make an organization agile top-down, it has to come both from top-down and bottom-up.

Gardner: I also hear people asking, “I have heard of Agile development, and now I am hearing about agile enterprise. Is this something different than DevOps, is it more than DevOps?” My impression is that it is much more than DevOps, but maybe we can address that. 

Mats, how does DevOps fit into this for those people that are thinking of agile only in terms of development?

Gejnevall: It depends on the normal way of doing Agile development, doing something in short iterations. And then you have some demos at the end, retrospectives, and some planning for the next iteration. And there is some discussion ongoing right now whether or not the demo needs to be something executable, that it’s used quickly in the organization. Or it could be just an architecture piece, a couple of models that are showing some aspect of things. In my view, it doesn’t have to be something executable. 

And also when you look at DevOps as well, there are a lot of discussions now about industrial DevOps, where you actually produce not software but other technical stuff in an agile way, with iterations, and you do it incrementally. 

Wrze?niewski: EA and architecture work as an enabler that allow for increasing complexity. We have many distributed teams that are working on the one product in DevOps, not run on Agile, and the complexity of the product, of the environment will be growing. 

Architecture can put it in a proper direction. And I mean intentional architecture that is not like big upfront design, like in traditional waterfall, but intentional architecture that enables the iterations and drives DevOps into the proper direction to reduce complexity -- and reduces the possibility of failure in product development. 

Gardner: I have also heard that architecture is about shifting from building to assembly, that it becomes repeatable and crosses organizational boundaries. Does anyone have a response to this idea of shifting from building to assembly and why it’s important? 

Strong building blocks bring success

Wrze?niewski: The use of microservices, containers, and similar technologies will mean components that you can assemble into entire products. These components are replaceable. It’s like the basic elements of EA when talking about the architecture and the building blocks, and good composition of the building blocks to deliver products. 

Architecture perfectly addresses this problem and shift. We have already had this concept for years in EA. 

Gardner: Anyone else on this topic of moving toward assembly, repeatability, and standardization?

Gejnevall: On the IT side, I think that’s quite common. It’s been common for many years in different ways and then new things happen. We talked about service-orientation for quite a while and then we started talking about microservices. These are all types of loosely coupled systems that become much more agile in certain ways. 

The interesting thing is to look at the business side of things. How can you make the business side become more agile? We have done a lot of workshops around service-orienting the business, making it capability-based and sustainable. The business consists of a bunch of services, so capabilities, and you can connect these capabilities to value streams and change the value streams in reaction to changes in the business side. That’s much easier than the old way of having strict boundaries between business units and business services that are developed.

We are now trying to move the thinking from the IT side up into the business side to enable the business to become much more componentized as you put different business services that the organization produces together in new ways and allow the management to come up with new and innovative ideas. 

Gardner: That gets to the heart of what we are trying to accomplish here. But what are some of the common challenges to attaining such agility, when we move both IT and the business to an agile perspective of being able to react and move, but without being brittle or having processes that can be extended -- without chaos and complexity? 

One of the challenges for the business architecture is the proper partitioning the architecture to distinguish the capabilities across the organizational silos.That means keeping the proper level of detail that is connected to the organizational strategy, and to be able to understand the system.

Wrze?niewski: One of the challenges for the business architecture is the proper partitioning of the architecture to distinguish the capabilities across the organizational silos. That means keeping the proper level of detail that is connected to the organizational strategy, and to be able to understand the system. Another big challenge is also to get the proper sponsorship for such activity and so to proceed with the transformation across the organization.

Gejnevall: Change is always hard for a lot of people. And we are trying to change, and to have people live in a more changeable world than they have been in before. That’s going to be very hard. Because people don’t like change, we are going to have to motivate people much more and have them understand why we need to change.

But change is going to be happening quicker and quicker, and if we create a much more agile enterprise, changes will keep rolling in faster and faster all of the time. 

Wrze?niewski: One of the areas where I ran into a problem when creating an architecture in an agile way was that if you have lots and lots of agile projects ongoing, or agile teams ongoing, you have to have a lot of stakeholders that come and watch these demos and have relevant opinions about them. From my past experiences of doing EA, it’s always hard to get the correct stakeholders’ involvement. And that’s going to be even harder, because now the stakeholders are looking at hundreds of different agile sprints at the same time. Will there be enough stakeholders for all of that?

Gardner: Right, of course you have to address the people, the process, and the technology, so the people, maybe even the most important part nowadays. 

Customer journey from finish to start

Gonzalez: With all of those agile digital trends, what is more important now is to have two things in mind, a product-centric view and the customer journey. In order to do that the different layers that aren’t traditional architecture are blurry, because now it’s not about business and IT anymore -- it’s about the organization as a whole that needs to be agile. 

And in that regard, for example, like Mats and ?ukasz have said, the right stakeholder needs to be in for the whole process. So it’s no longer saying, “I am the business, I am giving this request.” And then the IT people need to solve it. It’s not about that anymore. It’s having in mind that the product has services included, has an IT component, and also a business component.

When you are building your customer journey, just start from the very end, the connection with the customer, and move back all the way to the background and platform that are delivering the IT capabilities. 

So it’s about having a more cross view of doing architecture, which is important. 

Gardner: How does modeling and a standardized approach to modeling help overcome some of these challenges? What is it about what EA that allows for agility to become a common thread across an organization?

Wrze?niewski: When it comes to the modeling, the models are different, so different viewpoints are just the tools for EA. Enterprise Architects should choose proper means to define the architecture that should enable the change that the organization needs.

So the common understanding -- or maybe some stereotype of the Enterprise Architect -- is they are the guys that draw the lines and boxes and deliver only big documentation, but then nobody uses it. 

The challenge here is to deliver the MVPs in terms of modeling that the development teams and business will consider as something valuable and that can guide them. It’s not about making nice documentation, depositories in the tools, even if somebody is happy with some nice sketch on paper. It’s good architecture for the architect, because the architecture is about enabling the change in the organization and supporting the business and IT to deliver value, it’s not about only documenting every component. This is my opinion about what is the role of the architect and the model.

And, of course, we many different methods and conventions and the architect should choose the proper one for the organization. 

Model collaborations create solutions

Gejnevall: I don’t think that the architects should sit around and model on their own, it should be a collaboration between the solution architect and the solution developers in some ways. It’s a collaborative effort, where you actually work on the architecture together. So you don’t have to hand over a bunch of papers to the solution developers later on, they already know the whole stuff. 

So you are working in a continuous way of moving the material over to them, and you send it over to them in pieces, start with the most important pieces first or the slices of the architecture that is the most important and is most valuable, that’s sort of the whole Minimum Viable Architecture (MVA) approach. You can create lots of small MVAs, and then together with the solution teams allow them to work on that. It continuously creates new MVAs and the solution team continuously develops new MVPs. And that will go on for the entire length of a project, if that’s what you are working on, or for a product.

Gonzalez: In terms of modeling, there are at least two ways to see this. One of them is the fact that you need to model your high-level landscape for the enterprise in order to have this strategic view. You have some tools to identify which items you should have priorities for, going into your backlog and then going into the iteration, you need to be aligned with that. 

Also, for example, you can model high-level value streams, identify key capabilities and then try to define which one would be the item you would be delivering, in that you don’t need to do a lot of modeling, just high-level modeling which you are going to depict that.

Having lots of corporate architecture allows you to facilitate these different building blocks for changing. And there are lots of tools in the market now that will allow you to have automation in the things you are doing.

On the other hand, we have other models that are more solution-level-oriented and in that case, one of the challenges that architects have now in relationship to modeling is how to deal with the fact that models are changing – and should change faster now because trends are changing and the market is changing. So there are different techniques that can be used for that. For example, test-driven design, domain design, domain-driven design, refactoring, and some others that support agile modeling.

Also, like Mats mentioned, having lots of corporate architecture that would allow you to facilitate these different building blocks for changing. And there are a lot of tools in the market now that will allow you to have automation in the things you are doing. For example, to automate testing, which is something that we should do. It’s actually one of the key components of DevOps to automate the testing, to view how this facility really continues with the integration, the development, and finally, the delivery.

Gardner: Sonia, you mentioned automation, but a lot of organizations, enterprises and governments are saddled with legacy systems. That can be quite complex, having older back end systems that require a lot of manual support. How do we move past the restraints, if you will, of back-end systems, legacy systems, and still become agile? 

Combine old and new 

Gonzalez: That’s a very good question, Dana. That’s precisely one of the stronger things of our EA. ?ukasz mentioned that is the fact that you can use it in different ways and adapt it to different uses. 

So, you can, for example, if you have a bank where you usually have a lot of systems, you have legacy systems that are very difficult to change and risky to change. So, what a company should do is to have this combined approach saying, “Okay, I have a more traditional EA to handle my background systems because they are more stable and perhaps require fewer changes.”

But on the other hand, if you have your end-user platform, such as online banking or mobile banking, that development should be faster. You can have an agile view on that. So you can have a combined view. 

However, we also depend on the background. One of the things that companies are doing right now is to try to go over components and services, microservices, and outsourcing to build a corporate architecture for customer services platforms without having to change all the background systems at once because that’s very risky.

So it’s some kind of like a combined effort that it can be used in these cases.

Gardner: Anyone else have some insights on how to make agile EA backward compatible?

Wrze?niewski: What Sonia said is really important, that we have some sort of combined or hybrid approach for EA. You will always have some projects that run in the agile part, some projects that have a more traditional approach that are longer, and that the delivery of architecture will take a longer time to reduce the risk when we are replacing some, for example, core banking system. The role of the EA is to know how to combine these different approaches and how to find the silver bullets to solve all the different situations.

So, we wouldn’t be always looking for the organization on the one perspective that we are agile and everything that was before is a batch practice. We try to combine, and this is the evolution of organization’s new approach. So we will have to step by step improve the organization to get the best results if we are completely agile.

Gardner: Walters brought up the important issue of governance. How can agile EA allow organizations to be faster, focused on business outcomes, and also be more secure and more compliant? How does EA and agile EA help an organization attain both a secure and compliant environment?

Gejnevall: You need to have a security architecture, and that has to be set up in a very loosely coupled way so you can select the security features that are needed for your specific project. 

You need to have that security architecture as a reference model at the bottom of your architecture. That is something you need to follow. But then the security architecture is not just the IT part of it, it’s also the business side of things, because security has got a lot to do with the processes and the way a company works. 

All of that needs to be taken into consideration when we do the architecture and it needs to be known by all the solution development teams, these are the rules around security. I think you can’t let go early in that, but security architecture needs to be flexible as well, and it needs to be adapting continuously, because it needs to handle new threats all the time. You can’t do one security architecture and think it’s going to live there forever; it’s going to have the same type of renewal and refactoring things happening to it as anything else. 

Wrze?niewski: I would like to add that, in general, the agile approaches are more transparent and the testing of the security requirements often is done in an interactive way, so this approach can ensure higher security. 

Also, the governance should be adapted to the agile governance and some governance body that works in an agile way and you have different level of enterprise; I mean portfolio management, project management and teams. So, there is also some organizational change that needs to be done. 

Gardner: Many times when I speak with business leaders, they are concerned about mounting complexity, and one of the ways that they are very attracted to trying to combat complexity is to move towards minimum viable products and minimum viable services. How does the concept of an MVA help agility, but at the same time combat complexity? 

MVA moves product from plan to value

Wrze?niewski: MVA is the architecture of minimum viable products that can enable the development of the product. This can help you to solve the complexity issues with the minimum viable product to focus on this functionality, the capabilities that are mandatory for the organization and can deliver the highest percentage of value in the software.

And also if the minimum viable product fails, we don’t invest too much for the entire product development. 

Gejnevall: Inherently, organizations are complex. You have to start very much higher up than the IT side of it to take away complexity. You need to start at the business level, on the organizational level, on the process level, on how you actually do work. If that’s complex, the IT solutions for that will still be complex, so it needs to have a good EA and MVA can test out new things and new ways of organizing yourself, because everything doesn’t have to be an IT project in the end. 

You do an MVA and that’s a process change or an organization will change, you test it out and you say, did it actually minimize our complexity or did it actually increase our complexity, at least you can stop the project very quickly and go in another direction instead.

Gonzalez: Handling complexities is challenging, especially for big organizations that have been in the market for a long time. You will need to focus on the minimum viable product for leveraging the MVA, and go by slices, like taking smaller pieces to avoid going into much modeling. 

Handling complexity is challenging, especially for big organizations that have been in the market for a long time.You will need to focus on the minimum viable product for leveraging the MVA, and go by slices, like taking smaller pieces to avoid going into much modeling.

However, at the end, even though you are not conceding things to be only IT, at the end you have a platform which is the one that is providing your IT capabilities. In that case, my view is use of architecture is important. So you may have a more traditional EA for keeping the maintenance of your complex landscape. That’s already there. You cannot avoid that or ignore that, but you need to identify which components are there. 

So, whenever you are deciding a new problem with MVA, you can also be aware of the dependencies there at the platform level, which is where most of the time the complexities rely on. So that’s in my view a combined use again of both of them. 

And the other key thing here is having the good integration and automation tooling, because sometimes you need to do things manually and that’s where it takes a lot of time, so you just make some automations of that, then it will be easier to maintain and to allow you to handle that complexity without going against an agile view.

Gardner: And before we start to wrap up, I wanted to ask you what an organization will experience when they do leverage agile EA and become more adaptive in their business in total, holistically. What do you get when you do agile EA? What do you recognize as metrics of success if this is going well? 

Deliver value and value delivery

Gejnevall: Each one of these MVAs and minimum viable products is actually supposed to leave us some business value at the end. If you look a the framework like the TOGAF? standard, a standard of The Open Group, there is a phase at the end where you actually look at to see, “Did we really achieve this value that we expected to?” 

This a part of most product management frameworks as well. So we need to measure before we do something and then we need to measure afterward, did we get this business value that we expected, because just running a project at the demo, we can’t really tell if we got the value or not. We need to put it out in operations and measure it that way.

So getting that feedback loop much quicker than we did in the past when it took a couple of years to develop a new product and at the end of it we have changed and we didn’t get the value, even though we spent many million dollars to do that. Now we might spend a lot less money, but we can actually prove that we are getting some business value out of this and actually measure it appropriately as well.

Wrze?niewski: I agree fully with Mats that the value is quicker delivery. Also, the product quality should be much higher and all the people should be much more satisfied. I mean the team that delivers the service or product changes the business, the stakeholders, and direct clients. This really impacts the clients and team’s satisfaction. This is one of the important benefits of agile EA as well.

Gejnevall: Just because you have a term called minimum viable product and you think it always needs to be IT that’s doing that, I think you can do a minimum viable product in many other ways. Like I was saying before, process changes, organizational changes and other things. So it doesn’t always have to be IT that is doing the minimum viable product that gives you the best business value.

Gardner: How about the role of The Open Group? You have a number of certification programs, standards, workgroups, and you are talking with folks in the EA field all the time. What is it that The Open Group is bringing to the table nowadays to help foster agile EA and therefore better, more secure, more business-oriented companies and governments? 

Open Group EA and Agile offerings abound

Gonzalez: We have a series of standards from The Open Group. One of the subsets of that is the architecture portfolio. We have several activities going on. We have the Agile Architecture Framework snapshot, product of The Open Group Board Members’ activity which is already in the market for test and comments, but it’s not yet an approved standard. The Agile Architecture Framework? (O-AAF) covers both Digital Transformation of the enterprise, together with Agile Transformation of the enterprise considering concepts like Lean and DevOps among others.

On the other hand, we have the Architecture or the Agile EA one at the level of the Architecture Forum, which is the one Mats and ?ukasz are dealing with, of how to have an agile EA practice. There is a very good white paperpublished, and other deliverables, like a guide about how to use or make the TOGAF framework an agile sprint using the Architecture Development Method (ADM), so that’s another paper that is under construction, and there are also several that are on the way. 

We also have in the ArchiMate? Forum, we have Agile Modeling Activity, which is precisely dealing with the modeling part of this, so the three activities are connected. 

And into a separate working group, even though it is related, we have Digital Practitioners Work Group, aimed to address the digital enterprise. Also there is connection with the Agile Architecture Framework and we just started looking for some harmonization also with EA and the TOGAF standard. 

In the security space, we recently started the Zero Trust Architecture product, which is precisely trained to address this part of Zero Trust Architecture, which is securing the resources instead of securing the network. That’s a joint activity between Security Forum and the Architecture Forum. So, some of those are the things that are going on. 

And also at the level of the Agile Architecture Framework, there is also conversation about how to handle security and cloud in an agile environment, so you see we have several moving things at the table at the moment.

Gejnevall: Long-term, I think we need to look into agile enterprise much more, but I think that all these efforts sort of are converging up to that point sooner or later that we need to look to see what would an agile enterprise looks like and create reference architectures and ideas for that. And I think that that will be sort of the end result somewhere, but we are not there yet, but we are going in that direction with all these different projects. 

Gardner: And, of course, more information is available at The Open Group website. They have many global events and conferences that people can go to and learn about these issues and contribute to these issues as well. 

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: The Open Group.

You may also be interested in:

• How the ArchiMate modeling standard helps Enterprise Architects deliver successful digital transformation
• Where the rubber meets the road: How users see the IT4IT standard building competitive business advantage
• How an agile focus for Enterprise Architects builds competitive advantage for digital transformation
• How the data science profession is growing in value and impact across the business world
• The Open Group panel explores ways to help smart cities initiatives overcome public sector obstacles
• The Open Group digital practitioner effort eases the people path to digital business transformation
• How The Open Group Healthcare Forum and Health Enterprise Reference Architecture cures process and IT ills
• Why government agencies could lead the way in demanding inter-public cloud interoperability and standardization
• Panel explores how the IT4IT Reference Architecture acts as a digital business enabler