Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Friday, January 03, 2020

As Hybrid IT Complexity Ramps Up, Operators Look to Data-Driven Automation Tools

https://www.hpe.com/us/en/home.html

A discussion on the advancing role and impact from IT automation and how complex IT deployments are forcing managers to seek new productivity tools.

Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Hewlett Packard Enterprise.

Dana Gardner: Hello, and welcome to the next edition of the BriefingsDirect Voice of the Innovator podcast series. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator for this ongoing discussion on the latest insights into IT management strategies.

Gardner
Growing complexity from the many moving parts in today’s IT deployments are forcing managers to seek new productivity tools. Moving away from manual processes to bring higher levels of automation to data center infrastructure has long been a priority for IT operators, but now new tools and methods are making composability and automation better options than ever.

Here to help us learn more about the advancing role and impact from IT automation is Frances Guida, Manager of HPE OneView Automation and Ecosystem Product Management at Hewlett Packard Enterprise (HPE). Welcome, Frances.

Frances Guida: It’s great to be here, Dana.


Gardner: What are the top drivers, Frances, for businesses seeking higher levels of automation and simplicity in their IT infrastructure?

Guida: It relates to what’s happening at a business level. It’s a truism that business today is moving faster than it ever has before. That puts pressure on all parts of a business environment -- and that includes IT. And so IT needs to deliver things more quickly than they used to. They can’t just use the old techniques; they need to move to much more automated approaches. And that means they need to take work out of their operational environments.

Gardner: What’s driving the complexity that makes such automation beneficial?

IT means business 

Guida: It again starts from the business. IT used to be a support function, to support business processes. So, it could go along on its own time scale. There wasn’t much that the business could or would do about it.

Guida
In 2020, technology is now part of the fabric of most of the products, services, and experiences that businesses offer. So when technology is part of an offering, all of a sudden technology is how a business is differentiated. As part of how a business is differentiated, business leaders are not going to take, “Oh, we will get to it in 18 months,” as an answer. If that’s the answer they get from the IT department, they are going to go look for other ways of getting things done.

And with the advances of public cloud technology, there are other ways of getting things done that don’t come from an internal IT department. So IT organizations need to be able to keep up with the pace of business change, because businesses aren’t going to accept their historical time scale.

Gardner: Does accelerating IT via automation require an ecosystem of partners, or is there one tool that rules them all?

Guida: This is not a one-size-fits-all world. I talk to customers in our HPE Executive Briefing Centers regularly. The first thing I ask them is, “Tell me about the toolsets you have in your environment.” I often ask them about what kinds of automation toolsets they have. Do you have Terraform or Ansible or Chef or Puppet or vRealize Orchestrator or something else? It’s not uncommon for the answer to be, “Yes.” They have all of them.

So even within a customer’s environment, they don’t have a single tool. We need to work with all the toolsets that the customers have in their IT environments.

Gardner: It almost sounds like you are trying to automate the automation. Is that fair?

Guida: We definitely are trying to take some of the hard work that has historically gone into automation and make it much simpler.
Complexity is Growing in the Data Center
What's the Solution?
Gardner: IT operations complexity is probably only going to increase, because we are now talking about pushing compute operations -- and even micro data centers -- out to the edge in places like factories, vehicles, and medical environments, for example. Should we brace ourselves now for a continuing ramp-up of complexity and diversity when it comes to IT operations?

Guida: Oh, absolutely. You can’t have a single technology that’s going to answer everything. Is the end user going to interface through a short message service (SMS) or are they going to use a smartphone? Are they going to be on a browser? Is it an endpoint that interacts with a system that’s completely independent of any user base technology? All of this means that IT has to be multifaceted.

Even if we look at data center technologies, for the last 15 years virtualization has been pretty much the standard way that IT deploys new systems. Now, increasingly, organizations are looking at a set of applications that don’t run in virtual machines (VMs), but rather are container-based. That brings a whole other set of complexity they have to think about in their environments.
Complexity is like entropy; it just keeps growing. When we started thinking about bringing a lot more flexibility to on-premises data center environments, we looked holistically at the problem ... at a deeper level.

Complexity is like entropy; it just keeps growing. When we started thinking about bringing a lot more flexibility to on-premises data center environments, we looked holistically at the problem. I don’t think the problem can only be addressed through better automation; in fact, it has to be addressed at a deeper level.

And so with our composable infrastructure strategies, we thought architecturally about how we could bring the same kind of flexibility you have in a public cloud environment to on-premises data centers. We realized we needed a way to liberate IT beyond the boundaries of physical infrastructure by being able to group that physical infrastructure into pools of resources that could be much more fluid and where the physical aspects could be changed.

Now, there is some hardware infrastructure technology in that, but a lot of that magic is done through software, using software to configure things that used to be done in a physical manner.

https://community.hpe.com/t5/Shifting-to-Software-Defined/How-to-leverage-the-greatest-minds-in-the-world-in-your-own-data/ba-p/7031252#.XdgAk9VKiM8
So we defined a layer of software-defined intelligence that captures all of the things you need to know about configuring physical hardware -- whether it’s firmware levels or biased headings or connections. We define and calculate all of that in software.

And automation is the icing on that cake. Once you have your infrastructure that can be defined in software, you can program it. That’s where the automation comes in, being able to use everyday automation tools that organizations are already using to automate other parts of their IT environment and apply that to the physical infrastructure without a whole bunch of unnatural acts that were previously required if you wanted to automate physical infrastructure.

Gardner: Are we talking about a fundamental shift in how infrastructure should be conceived or thought of here?

Consolidate complexity via automation 

Guida: There has been a saying in the IT industry for a while about moving from pets to cattle. Now we even talk about thinking about herds. You can brute-force that transition by trying to automate to all of the low-level application programing interfaces (APIs) in physical infrastructure today. Most infrastructure today is programmable, with rare exceptions.

But then you as the organization are doing the automation, and you must internalize that and make your automation account for all of the logic. For example, if you then make a change in the storage configuration, what does that mean for the way the network needs to be configured? What does that mean for firmware settings? You would have to maintain all of that in your own automation logic.
How to Simplify and Automate
Your Data Center
There are some organizations in the world that have the scale of automation engineering to be able to do that. But the vast majority of enterprises don’t have that capability. And so what we do with composable infrastructure, HPE OneView, and our partner ecosystem is we actually encapsulate all of that in our software to find intelligence. So all you have to do is take that configuration file and apply it to a set of physical hardware. It brings things that used to be extremely complex down to what a standard IT organization has the capabilities of doing today.

Gardner: And not only is that automation going to appeal to the enterprise IT organizations, it’s also going to appeal to the ecosystem of partners. They now have the means to use the composable infrastructure to create new value-added services.

How does HPE’s composability benefit both the end-user organizations and the development of the partner ecosystem?

Guida: When I began the composable ecosystem program, we actually had two or three partners. This was about four years ago. We have now grown to more than 30 different integrations in place today, with many more partners that we are talking to. And those range from the big, everyday names like VMware and Microsoft to smaller companies that may be present in only a particular geography.

https://www.hpe.com/us/en/home.html
But what gets them excited is that, all of a sudden, they are able to bring better value to their customers. They are able to deliver, for example, an integrated monitoring system. Or maybe they are already doing application monitoring, and all of a sudden they can add infrastructure monitoring. Or they may already be doing facilities management, managing the power and cooling, and all of a sudden they get a whole bunch of data that used to be hard to put in one place. Now they can get a whole bunch of data on the thermals, of what’s really going on at the infrastructure level. It’s definitely very exciting for them.


Gardner: What jumps out at you as a good example of taking advantage of what composable infrastructure can do?

Guida: The most frequent conversations I have with customers today begin with basic automation. They have many tools in their environment; I mentioned many of them earlier: Ansible, Terraform, Chef, Puppet, or even just PowerShell or Python; or in the VMware environment, vRealize Orchestrator.

They have these tools and really appreciate what we have been able to do with publishing these integrations on GitHub, for example, of having a community, and having direct support back to our engineers who are doing this work. They are able to pretty straightforwardly add that into their tools environment.
How a Software-Defined Data Center
Lets the Smartest People Work for You
And we at HPE have also done some of the work ourselves in the open source tools projects. Pretty much every automation tool that’s out there in mainstream use by IT -- we can handle it. That’s where a lot of the conversations we have with customers begin.

If they don’t begin there, they start back in basic IT operations. One of the ways people take advantage of the automation in HPE OneView -- but they don’t realize they are taking advantage of automation -- is in how OneView helps them integrate their physical infrastructure into a VMware vCenter or a Microsoft System Center environment.

Visualize everything, automatically 

For example, in a VMware vCenter environment, an administrator can use our plug-in and it automatically sucks in all of the data from their physical infrastructure that’s relevant to their VMware environment. They can see things in their vCenter environment that they otherwise couldn’t see.

They can see everything from a VM that’s sitting on the VM host that’s connected through the host bus adapters (HBAs) out to the storage array. There is the logical volume. And they can very easily visualize the entire logical as well as physical environment. That’s automation, but you are not necessarily perceiving it as automation. You are perceiving it as simply making an IT operations environment a lot easier to use.
The automation benefits -- instead of just going down into the IT operations -- can also go up to allow more cloud management. It affects infrastructure and applications.

For that level of IT operations integration, VMware and Microsoft environments are the poster children. But for other tools, like Micro Focus and some of the capacity planning tools, and event management tools like ServiceNow – those are another big use case category.

The automation benefits – instead of just going down into the IT operations – can also go up to allow more cloud management. Another way IT organizations take advantage of the HPE automation ecosystem means, “Okay, it’s great that you can automate a piece of physical infrastructure, but what I really need to do -- and what I really care about -- is automating a service. I want to be able to provision my SQL database server that’s in the cloud.”

That not only affects infrastructure pieces, it touches a bunch of application pieces, too. Organizations want it all done through a self-service portal. So we have a number of partners who enable that.

Morpheus comes to mind. We have quite a lot of engagements today with customers who are looking at Morpheus as a cloud management platform and taking advantage of how they can not only provision the logical aspects of their cloud, but also the physical ones through all of the integrations that we have done.
How to Simplify, Automate, and
Develop Faster
Gardner: How does HPE and the partner ecosystem automate the automation, given the complexity that comes with the newer hybrid deployment models? Is that what HPE OneView is designed to help do these days?

Automatic, systematic, cost-saving habit 

Guida: I want to talk about a customer who is an online retailer. If you think about the retail world -- obviously a highly dynamic world and technology is at the very forefront of the product that they deliver; technology is the product that they deliver.

They have a very creative marketing department that is always looking for new ways to connect to their customers. That marketing department has access to a set of application developers who are developing new widgets, new ways of connecting with customers. Some of those developers like to develop in VMs, which is more old school; some of the developers are more new school and they prefer container-based environments.

The challenge the IT department has is that from one week to the next they don’t fully know how much of their capacity needs to be dedicated to a VM versus a container environment. It all depends on which promotions or programs the business decides it wants to run at any time.

So the IT organization needed a way to quickly switch an individual VM host server to be reconfigured as a bare-metal container host. They didn’t want to pay a VM tax on their container host. They identified that if they were going to do that manually, there were dozens and dozens -- I think they had 36 or 37 -- steps that they needed to do. And they could not figure out a way to automate individually each one of those 37 steps.
When we brought them an HPE Synergy infrastructure -- managed by OneView, automated by Ansible -- they instantly saw how that was going to help solve their problems. They were able to change their environemnt from one personality to another in a completely automated fashion.

When we brought them an HPE Synergy infrastructure -- managed by OneView, automated with Ansible -- they instantly saw how that was going to help solve their problems. They were going to be able to change their environment from one personality to another personality in a completely automated fashion. And now they are able to do that changeover in just 30 minutes, and instead of needing dozens of manual steps. They have zero manual steps; everything is fully automated.

And that enables them to respond to the business requirements. The business needs to be able to run whatever programs and promotions it is that they want to run -- and they can’t be constrained by IT. Maybe that gives a picture of how valuable this is to our customers.

Gardner: Yes, it speaks to the business outcomes, which are agility and speed, and at the same time the IT economics are impacted there as well.

Speaking of IT economics and IT automation, we have been talking in terms of process and technology. But businesses are also seeking to simplify and automate the economics of how they acquire and spend on IT, perhaps more on a pay-per-use basis.

Is there alignment between what you are doing in automation and what HPE is doing with HPE GreenLake? Do the economics and automation reinforce one another?
How to Drive Innovation and
Automation in Your Data Center
Guida: Oh, absolutely. We bring physical infrastructure flexibility, and HPE GreenLake brings financial flexibility. Those go hand in hand. In fact, the example that I was just speaking about, the online retailer, they are very, very busy during the Christmas shopping season. They are also busy for Valentine’s Day, Mother’s Day, and back-to-school shopping. But they also have times where they are much less busy.

They have HPE GreenLake integrated into their environment so in addition to having the physical flexibility in their environment, they are financially aligning through a flexible capacity program and paying for technology -- in the way that their business model works. So, these things go hand-in-hand.

https://www.hpe.com/us/en/services/flexible-capacity.html?chatsrc=ot-en&jumpid=ps_muqbvc5xh2_aid-510455007&gclid=EAIaIQobChMIgbTwgZr-5QIViLzACh0c8AkNEAAYASAAEgLi_fD_BwE&gclsrc=aw.ds

As I said earlier, I talk to a lot of HPE customers because I am based in the San Francisco Bay Area where we have our corporate headquarters. I am frequently in our Executive Briefing Center two to three times a week. There are almost no conversations I am part of that don’t lead eventually to the financial aspects, as well as the technical aspect, of how all the technology works.

Gardner: Because we have opened IT automation up to the programmatic level, a new breed of innovation can be further brought to bear. Once people get their hands on these tools and start to automate, what have you seen on the innovation side? What have people started doing with this that you maybe didn’t even think they would do when you designed the products?

Single infrastructure signals innovation 

Guida: Well, I don’t know that we didn’t think about this, but one of the things we have been able to do is make something that the IT industry has been talking about for a while in an on-premises IT environment.

There are lots of organizations that have IT capacity that is only used some of the time. A classic example is an engineering organization that provides a virtual desktop infrastructure (VDI) capability for engineers. These engineers need a bunch of analytics applications -- maybe it’s genomic engineering, seismic engineering, or fluid dynamics in the automotive industry. They have multiple needs. Typically they have been running those on different sets of physical infrastructures.

With our automation, we can enable them to collapse that all into one set of infrastructure, which means they can be much more financially efficient. Because they are more financially efficient on the IT side, they are able to then devote more of their dollars to driving innovation -- finding new ways of discovering oil and gas under the ground, new ways of making automobiles much more efficient, or uncovering new secrets within our DNA. By spending less on their IT infrastructure, they are able to spend more on what their core business innovation should be.

Gardner: Frances, I have seen other vendors approach automation with a tradeoff. They say, “Well, if you only use our cloud, it’s automated. If you only use our hypervisor, it’s automated. If you only use our database, it’s automated.”

But HPE has taken a different tack. You have looked at heterogeneity as the norm and the complexity as a result of heterogeneity as what automation needs to focus on. How far ahead is HPE on composability and automation? How differentiated are you from others who have put a tradeoff in place when it comes to solving automation?
We have had composable infrastructure on the market for three-plus years. Our HPE Synergy platform now has a $1 billion run rate. We have 3,600 customers around the world. It's been a tremendously successful business for us.

Guida: We have had composable infrastructure on the market for three-plus years now. Our HPE Synergy platform, for example, now has a more than $1 billion run rate for HPE. We have 3,600 customers and counting around the world. It’s been a tremendously successful business for us.

I find it interesting that we don’t see a lot of activity out there, of people trying to mimic or imitate what we have done. So I expect composability and automation will remain fundamentally differentiating for us from many of our traditional on-premises infrastructure competitors.

It positions us very well to provide an alternative for organizations who like the flexibility of cloud services but prefer to have them in their on-premises environments. It’s been tremendously differentiating for us. I am not seeing anyone else who has anything coming on hot in any way.

Gardner: Let’s take a look to the future. Increasingly, not only are companies looking to become data-driven, but IT organizations are also seeking to become data-driven. As we gather more data and inference, we start to be predictive in optimizing IT operations.

I am, of course, speaking of AIOps. What does that bring to the equation around automation and composability? How will AIOps change this in the coming couple of years?

Automation innovation in sight with AIOps 

Guida: That’s a real opportunity for further innovation in the industry. We are at the very early stages about how we take advantage in a symptomatic way of all of the insights that we can derive from knowing what is actually happening within our IT environments and mining those insights. Once we have mined those insights, it creates the possibility for us to take automation to another level.

We have been throwing around terms like self-healing for a couple of decades, but a lot of organizations are not yet ready for something like self-healing infrastructure. There is a lot of complexity within our environments. And when you put that into a broader heterogeneous data center environment, there is even more complexity. So there is some trepidation.
How to Accelerate to
A Self-Driving Data Center
Over time, for sure, the industry will get there. We will be forced to get there because we are going to be able to do that in other execution venues like the public cloud. So the industry will get there. The whole notion of what we have done with automation of composable infrastructure is absolutely a great foundation for us as we take our customers toward these next journeys around automation.

Gardner: I’m afraid we’ll have to leave it there. We have been exploring how growing complexity from the many moving parts in IT deployments have forced managers to seek new levels of productivity. And we have also learned about the advancing role and impact of IT composability and automation to better manage today’s dynamic and extensive data center deployments.

So please join me in thanking our guest, Frances Guida, Manager of HPE OneView Automation and Ecosystem Product Management at HPE. Thank you so much, Frances.

Guida: I enjoyed our conversation.


Gardner: And a big thank you as well to our audience for joining us for this sponsored BriefingsDirect Voice of the Innovator IT management strategies interview. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this ongoing series of HPE-sponsored discussions.

Thanks again for listening. Please pass this on to your community, and do come back next time.

Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Hewlett Packard Enterprise.

A discussion on the advancing role and impact from IT automation and how complex IT deployments are forcing managers to seek new productivity tools. Copyright Interarbor Solutions, LLC, 2005-2020. All rights reserved.

You may also be interested in:

Monday, December 16, 2019

How Agile Enterprise Architecture Builds Agile Business Advantage

https://blog.opengroup.org/category/agile-architecture-framework/

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.

Gardner
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?

EA’s holistic point of view

Gejnevall
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.

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:
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.

http://www.opengroup.org/
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
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.”

Obenson
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?

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.

http://www.opengroup.org/

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.

http://www.opengroup.org/

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.

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.

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: