In his on-demand webinar, “EA in the Face of Digital Disruption,” Cutter Consortium Senior Consultant Roger Evernden explored some of the issues enterprise architects are facing with digital disruption. He tackled how organizations and entire industries must rethink value — creating and capturing it — to meet the challenges that digital brings to our lives. In this Advisor, we share some of the questions addressed in the Q&A portion of the webinar.
Q: What is the value for enterprise architecture (EA) within Agile practices, and what do you measure?
Roger Evernden: Agile is all about doing things quicker and having those iterations so that you focus very clearly on what you can do in the short term and how you actually build up to create a comprehensive future, so it’s a cumulative, iterative approach. We need to do that in EA a lot more. In the past, a lot of enterprise architecture programs were very heavy on the planning and getting the overall strategy — and then almost doing a kind of a sequential waterfall-type of approach, where you drop down to the detailed development. We need to change that. We need to have much more of an iterative approach.
Interestingly, I have been working recently with an organization that’s adopted EA and Agile technologies and approaches. We’ve been working on a way of building their capabilities on an iterative basis, so we’ve been doing just-in-time building of their EA capability in parallel with their iterative, scrum-based approach for Agile. The two are very complementary and work together, but we certainly could do a lot more to improve the way that they’re linked and to make EA a lot more agile.
Q: What is the future role of EA in the digital economy and how can EA reinvent itself and add value to the organization?
Evernden: In the short term, the most important thing is to recognize that the boundary enterprise is no longer really the valid one. You have to know that a significant number of the components that make up your architecture are outside of the boundary of the enterprise. That’s why it’s important to talk about the specific domains that are within your control as well as the ones that are outside your control.
As we move more to digital technologies, increasingly some of those infrastructure components that used to be inside the boundary of the architecture are now outside the boundary, so we don’t have the direct control of those components. We might be able to influence their future; we might be able to engage in consortia and groups that create those components; but we don't have the direct control. So, I think the most important thing in the short term is recognizing that shift in the boundary and understanding which elements are within scope and in your control, and which elements are in scope but outside your control.
The second thing that I would do is, once you’ve looked at that and how it affects your enterprise, look very carefully at the layers and the pillars that form the basis of your EA and work out which of those are still within your control and which are partially in control or outside your control. Then, redraw the pattern that describes those pillars and layers so you’ve got a clear picture of what your future EA — or even your current EA — looks like, because that isn't architecturally explicit for many organizations.
Q: I am interested in EA at speed. Can it be done, and if so, how?
Evernden: Absolutely it can be done. It depends somewhat on the aptitude of your organization to embrace that. A lot of the reason why EA is a bit slow and cumbersome in some organizations is because those organizations have a culture of doing things in a slow, cumbersome way! I’ve done a lot of work with banks around the globe, and typically banks tend to allow a lot of time for major changes. It doesn’t have to be that way. It’s much better if you have an iterative approach. It’s much better if you do a very quick, high-level pass and understand what your vision and target options are for the EA and pick the key parts of that change that are really going to give you the best benefit and do those quickly and have an overview that allows you to prioritize and see those options.
The key techniques you need for doing this are: first, you need to know what the strategic themes are for your enterprise. What are the key things that the stakeholders and key decision makers want to achieve? And once you’ve got those strategic themes, you need to think about what I call “strategic vectors.” In most organizations, you have lots of investment, lots of resources, lots of things going on, and very little overall coordination that ensures everything is working together. Or, if there is any coordination, it is at the project and program level, not at the architectural level. You need a mechanism that makes sure that all of that effort contributes to the overall evolution of the EA.
That’s what a strategic vector does: it’s a way of assessing all of the potential investments and the actual investments and programs and projects, and working out to what degree they contribute to the architectural evolution, how quickly they contribute to it, and what is the overall impact of the change.
Once you start looking at those strategic vectors, it gives you a mechanism to work out how you can speed things up. You can change the order in which things happen. You can prioritize things that, if you put them in place, give you a foundation for multiple projects. By doing that, it has a snowball effect, where your initial change that was a quick change actually affects other things in the future.
Q: How/when should blockchain be incorporated into EA?
Evernden: It comes back to four basic levels of architectural understanding: architectural, solution/design, development/implementation, and operational/systems. The reason for separating those levels out is that if you don’t think about the architecture before you start thinking about solutions and design, or if you drop down to development and implementation or even operations without thinking of the higher levels, then it becomes much harder to coordinate and integrate new technologies like blockchain with other elements in your architecture. So you need to have a clear architectural view, and that clear architectural view then helps you to decide where and when new technologies and new solutions actually fit in. It helps you make decisions on whether you need to do some design work and development work or whether you tap into someone else’s solution and design work. Or whether you just go straight down to a predefined infrastructure or platform that already exists.
Those layers of architectural understanding are vital in getting a clear view when anything is introduced to the architecture. If you haven’t got a clear picture of the evolution of your architecture in terms of how you're changing those basics, it will be harder. This goes back a little bit to my answer to a previous question: if you know the layers and the pillars of the architecture, and you know which ones are within your direct control and which ones you need to collaborate with others or are completely outside your control, then it’s much easier to make those decisions about specific technologies.
The broad change that’s taking place for most digital changes and digital technologies is that things are switching from inside what used to be the control of the EA team to something that is defined and available outside or that uses a lot of outside components. Getting that big-picture overview first will help you make decisions on specific technologies.
Q: Should it be called “ecosystem architecture” instead of EA to recognize the shift in boundary and recognize the scope of work?
Evernden: There are quite a few people who are writing about ecosystems and ecosystem architecture. To me, it doesn’t matter too much what we call it. What’s most important to me is to actually step back a level beyond that and to say that architectural thinking is a different way of thinking about the overall context for anything. We apply architectural thinking whether we’re looking at a building or an enterprise or an ecosystem. It almost doesn’t matter what label we apply to it, because when we actually come to scope a project, we’re going to identify name and specify the domains, the subdomains, and the components that we’re dealing. If we’ve got a project that’s dealing with a bigger picture, then it’s going to go beyond what we used to have in an enterprise. It’s going to go beyond applications, and it might include things like brand or event or business rule. All of these are possible things that you might want to include, whether that’s an ecosystem or an enterprise. It almost doesn’t matter. The important thing is that you apply architectural techniques to raise the discussion to the architectural level of understanding. It’s one of the reasons that I came up with this concept of the levels of understanding. It’s so important to realize that what we’re doing as enterprise architects is raising that discussion to the architectural level — over and over and over again.