Transcript of a discussion on how Enterprise Architecture defines and supports more agile business methods and builds competitive advantages for enterprises and governments.

1. Page 1 of 14
How Agile Enterprise Architecture
Builds Agile Business Advantage
Transcript of a discussion on how Enterprise Architecture defines and supports more agile
business methods and builds competitive advantages for enterprises and governments.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: The Open
Group.
Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and
you’re listening to BriefingsDirect. Our next 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 can embrace agile approaches to build
competitive advantages for enterprises and governments, as well as to keep those
organizations more secure and compliant.
To learn more about attaining agility by the latest EA approach, we are now joined by
our panel, Mats Gejnevall, Enterprise Architect at minnovate and Member of The Open
Group Agile Architecture Work Group. Welcome, Mats.
Mats Gejnevall: Thanks, Dana.
Gardner: We are also here with Sonia Gonzalez, Forum Director of the Architecture
Forum at The Open Group. Welcome, Sonia.
Sonia Gonzalez: Thank you very much, Dana.
Gardner: And we are here as well with Walters
Obenson, Director of the Agile Architecture Framework at
The Open Group. Welcome, Walters.
Walters Obenson: Thank you, Dana.
Gardner: And lastly, we are also here with Łukasz
Wrześniewski, Enterprise Architect and Agile
Transformation Consultant. Welcome, Łukasz.
Łukasz Wrześniewski: Welcome all.
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?
Obenson

2. Page 2 of 14
EA’s holistic point of view
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.
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.
To create a true agile EA, the
whole organization needs to be
agile, it’s not just the IT part.
Gejnevall

3. Page 3 of 14
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.
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.
Wrześniewski

4. Page 4 of 14
It’s a change of mindset that will automatically make you change the way you are doing
EA.
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?
EA and architecture work
as an enabler that allows for
increasing complexity.

5. Page 5 of 14
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?
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.
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.

6. Page 6 of 14
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?
Gonzalez

7. Page 7 of 14
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.
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.

8. Page 8 of 14
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.
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
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.

9. Page 9 of 14
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.
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.

10. Page 10 of 14
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
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.

11. Page 11 of 14
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 longer time, the new ones. 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.
The key thing here is having the
good integration and automation
tooling … then it will be easier
to maintain and … to handle
that complexity without going
against an agile view.

12. Page 12 of 14
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.
The value is quicker delivery.
Also, the product quality should
be much higher and all the people
should be much more satisfied.

13. Page 13 of 14
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.
I’m afraid we will have to leave it there. You have been listening to a sponsored
BriefingsDirect discussion on how EA defines and supports more agile business
methods and outcomes. And we have learned how agile EA can embrace approaches to
build competitive advantages for both enterprises and governments as well keep those
organizations more secure and compliant.
So a big thank you to our panel, Mats Gejnevall, Enterprise Architect at minnovate and
Member of The Open Group Agile Enterprise Architecture Work Group. Thank you,
Mats.
Gejnevall: Thank you, Dana.
Gardner: We have also been here with Sonia Gonzalez, Forum Director for the
Architecture Forum at The Open Group. Thank you, Sonia.
Gonzalez: Thank you very much, Dana.
Gardner: We have been joined by Walters Obenson, Director of the Agile Architecture
Framework at The Open Group. Thank you, Walters.
Obenson: Thank you, Dana.

14. Page 14 of 14
Gardner: And lastly, a big thank you to Łukasz Wrześniewski, the Enterprise Architect
and Agile Transformation Consultant. Thank you, Łukasz.
Wrześniewski: I am also a Member of The Open Group. Thank you, Dana.
Gardner: And a big thank you as well to our audience for joining this BriefingsDirect
agile business innovation discussion. I’m Dana Gardner, Principal Analyst at Interarbor
Solutions, your host throughout this series of BriefingsDirect discussions sponsored by
The Open Group.
Thanks again for listening, please pass this along to your IT community, and do come
back next time.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: The Open
Group.
Transcript of a discussion on how Enterprise Architecture defines and supports more agile
business methods and builds competitive advantages for enterprises and governments. Copyright
Interarbor Solutions, LLC and The Open Group, 2005-2019. All rights reserved.
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