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 |
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: |
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.
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 |
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.”
 |
| Obenson |
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?
Security architecture essential
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
paper published, 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
