Friday, December 27, 2019

Healthcare providers define new ways to elevate and improve the digital patient experience

https://www.healthpay24.com/

The next BriefingsDirect healthcare insights discussion explores ways to improve the total patient experience -- including financial considerations -- using digital technology.

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

To learn more about ways that healthcare providers are seeking to leverage such concepts as customer relationship management (CRM) to improve their services we are joined by Laura Semlies, Vice President of Digital Patient Experience, at Northwell Health in metro New York; Julie Gerdeman, CEO at HealthPay24 in Mechanicsburg, Penn., and Jennifer Erler, Cash Manager in the Treasury Department at Fairview Health Services in Minneapolis. The panel is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.


Here are some excerpts:

Gardner: Laura, digital patient experiences have come a long way, but we still have a long way to go. It’s not just technology, though. What are the major components needed for improved digital patient experience?

Semlies: Digital, at the end of the day, is all about knowing who our patients are, understanding what they find valuable, and how they are going to best use tools and assets. For us the primary thing is to figure out where the points of friction are and how digital then has the capability to help solve that.

Semlies
If you continuously gain knowledge and understanding of where you have an opportunity to provide value and deliberately attack each one of those functions and experiences, that’s how we are going to get the best value out of digital over time.

So for us that was around knowing the patient in every moment of interaction, and how to give them better tools to access our health system -- from an appointments’ perspective, to drive down the redundant data collection, and give them the ability to both pay their bills online and to not be surprised when they get their bill and the amount. Those are the things that we focused on, because they were the highest points of friction and value as articulated by our patients.

Where we go next is up to the patients. Frankly, the providers who are struggling with the technology between them and their patients [also struggle] in the relationship itself.

Partner with IT to provide best care

Gardner: Jennie, the financial aspects of a patient’s experience are very important. We have separate systems for financial and experience. Should we increasingly be talking about both the financial and the overall care experience?

Erler
Erler: We should. Healthcare organizations have an opportunity to internally partner with IT. IT used to be an afterthought, but it’s coming to the forefront. IT resources are a huge need for us in healthcare to drive that total patient experience.

As Laura said, we have a lot of redundant data. How do we partner with IT in the best way possible where it benefits our customers’ experience? And how do they want that delivered? Looking at the industry today, I’m seeing Amazon and Walmart getting into the healthcare field.

As healthcare organizations, perhaps we didn’t invest heavily in IT, but I think we are trying to catch up now. We need to invest in the relationship with IT -- and all the other operational partners -- to deliver to the patients in the best way possible.

Gardner: Julie, doesn’t making technology better for the financial aspects of the patient experience also set the stage for creating an environment and the means to accomplish a total digital patient experience?

Gerdeman: It does, Dana. We see the patient at the center of all those decisions. So put the patient at the center, and then engage with that patient in the way that they want to engage. The role that technology plays is to personalize digital engagement. There is an opportunity in the financial engagement of the patient to communicate; to communicate clearly, simply, so that they know what their obligation is -- and that they have options. Technology enables options, it enables communication, and that then elevates their experience. With the patient at the center, with technology enabling it, that takes it to a whole other level.

Learn to listen; listen to learn 

Semlies: At the end of the day, technology is about giving us the tools to be active listeners. Historically it has been one-directional. We have a transaction to perform and we go when we perform that transaction.

In the tomorrow-state, it becomes much more of a dialogue. The more we learn about an individual, and the more we learn about a behavior, the more we learn what was a truly positive experience -- or a negative experience. Then we can take those learnings and activate them in the right moments.
We just don't have the tools yet to actively listen and understand how to get to a higher level of personalization. Most of our investment is now going to figure out what we need to be actively listening.

It’s always impressive to me when something pops up on my Amazon cart as a recommendation. They know I want something before I even know I want something. What is the analogy in healthcare? It could be a service that I need and want, or a new option that would be attractive to me, that’s inherently personalized. We just don’t have the tools yet to actively listen and understand how to get to that level of personalization.

Most of our investment is now going to figure out what do we need so that we can be actively listening -- and actively talking in the right voice to both our providers and our patients to drive better experiences. Those are the things that other industries, in my opinion, have a leg up on us.

We can do the functions but connecting those functions and getting to where we can design and cultivate simple experiences that people love -- and drive loyalty and relationships – that’s the magic sauce.
Gain a Detailed Look at Patient
Financial Engagement Strategies
Gardner: It’s important to know what patients want to know, when they want to know it, and maybe even anticipate that across their experience. What’s the friction in the process right now? What prevents the ultimate patient experience, where you can anticipate their needs and do it in a way that makes them feel comfortable? That also might be a benefit to the payers and providers.

Erler: Historically, when we do patient surveys, we ask about the clinical experience. But maybe we are not asking patients the right questions to get to the bottom of it all. Maybe we are not being as intuitive as we could be with all the data we have in our systems.

It’s been a struggle from a treasury perspective. I have been asking, “Can we get a billing-related question on the survey?” That’s part of their experience, too, and it’s part of their wellness. Will they be stressing about what they owe on my bill and what it is going to cost them? We have to take another look at how we serve our patients.

We need to be more in-the-moment instead of after-the-fact. How was your visit and how can we fix it? How can we get that feedback right then and there when they are having that experience?

Gardner: It’s okay to talk about the finances as part of the overall care, isn’t it?

Erler: Right!

Healthy money, healthy mind 

Gerdeman
Gerdeman: Yeah, absolutely. We recently conducted a study with more than 150 providers at HealthPay24. What we found is a negative billing-financial experience can completely negate the fabulous clinical experience from a healthcare provider. Really, it can leave such a bad impression.

To Jennie’s point, by asking questions -- not just around the clinical experience, but around the financial experience, and how things can be improved – allows patients to get back to their options and the flexibility is provided in a personalized way, based on who they are and what they need.

Semlies: The other component of this is that we are very organized around transactional interactions with patients, but when it comes to experience -- experience is relationship-based. Odds are you don’t have one bill coming to you, you have multiple bills coming to you, and they come to you with multiple formats, with multiple options to pay, with multiple options to help you with those bills. And that is very, very confusing, and that’s in one interaction with the healthcare system.

If you connect that to a patient who is dealing with something more chronic or more serious, they could have literally 20, 30, 40 or 100 bills coming in. That just creates such an exasperation for our patients -- and frustration.

https://www.northwell.edu/
Our path to solving this needs to be far less around single transactions and far broader. It demands that the healthcare systems think differently about how they approach these problems. Patients don’t experience one bill; they experience a series of bills. If we give them different support numbers, different tools, different options for each and every one of those, it will always be confusing – no matter how sophisticated the tool that you use to pay the bill is.

Gardner: So the idea is to make things simpler for the patient. But there is an awful lot of complexity behind the scenes in order to accomplish that. It’s fundamentally about data and sharing data. So let’s address those two issues, data and complexity. How do we overcome those to provide improved simplicity?

Erler: We have all the information we need on a claim that goes to the payer. The payer knows what they are going to pay us. How do we get more married-up with the payer so that we can create that better experience for our customers? How do we partner better with the payers to deliver that information to the patients?

How do we start to individualize our relationships with patients so we know how they are going to behave and how they are going to interact? How do we partner better with the payers to deliver information to the patients?
And then how do we start to individualize our relationships with patients so we know how they are going to behave and how they are going to interact?

I don’t know that patients are aware of the relationship that we as providers have with our payers, and how much we struggle just to get paid. The data is in the claim, the payer has the data, so why is it so difficult for us to do what we need with that data on the backend? We need to make that simpler for everybody involved.

Gardner: Julie … people, process, and technology. We have seen analogs to this in other industries. It is a difficult problem. What technologically and culturally do you think needs to happen in order for these improvements to take place?

Connect to reduce complexity 

Gerdeman: It’s under way and it’s happening. The generations and demographics are changing in our society and in our culture. As the younger generations become patients, they bring with them the expectation that data is at their fingertips and that technology enables their lives, wherever they are and whatever they are doing, because they have a whole other view.

Millennials, the younger generations, have a different perspective and expectations around wellness. There is a big shift happening -- not just care for being sick, but actual wellness to prevent illness. The technology needs to engage with that demographic in a new way and understanding.

Laura used the word connection. Connection and interoperability are truly how we address the complexity you referenced. Through that connection, the technology enables IT to be interoperable with all the different health systems hospitals use. That’s how we are going to solve it.

Gardner: We are also seeing in other industries an interesting relationship between self-help, or self-driven processes, and automation. They complement one another, if it’s done properly.

Do you see that as an opportunity in healthcare, where the digital experience gives the patient the opportunity to drive their own questions and answers, to find their own way should they choose? Is automation a way that makes an improved experience possible?
Gain a Detailed Look at Patient
Financial Engagement Strategies
Semlies: Absolutely. Self-help is one of the first things we first went live with using HealthPay24 technology. We knew the top 20 questions that patients were calling in about. We had lots of toolkits inside the organization, but we didn’t expose that information. It lived on our website somewhere, but it didn’t live in our website in a direct, easy to read, easy to understand way. It was written in our voice, not the patient’s voice, and it wasn’t exposed at the moment that a patient was actually making that transaction.


Part of the reason why we have seen such an increase in our online payments is because we posted literally, quite simply, frequently asked questions (FAQ) around this. Patients don’t want to call and wait 22 minutes to get an agent to hear them if they can self-serve themselves. And it’s really helped us a lot, and there is an analogy in that in lots of different places in the healthcare space.

Gardner: You need to have the right tools and capabilities internally to be able to satisfy the patient requirements. But the systems internally don’t always give you that single view of the patient, like what a customer relationship management (CRM) system does in other industries.

Would you like to have a complement to a CRM system in healthcare so that you have all the information that you need to interact properly?

Healthcare CRM as a way of life

Semlies: CRM is something that we didn’t talk about in healthcare previously. I very much believe that CRM is as much about an ethos and a philosophy as it is about a system. I don’t believe it is exclusively a system. I think it’s a way of life, an understanding of what the patient needs. You can have the information at your fingertips in the moment that you need it and be able to share that.

I think we’re evolving. We want to be customer-obsessed, but there is a big difference between wanting to be customer-obsessed and actually being customer-obsessed.

The other challenge is there are some inherent conflicts when you start talking about customer obsession and what other stakeholders inside the health system want to do with their patients, but it can be really hard to deliver. When a patient wants a real-time answer to something and your service level agreement (SLA) is a day, you can’t meet their expectation.
We're evolving. We want to be customer-obsessed, but there is a big difference between wanting to be cusomter-obsessed and actually being customer-obsessed. It can be really hard to deliver.

And so how do you rethink your scope of service? How do you rethink the way you provide information to individuals? How do you rethink providing self-help opportunities so they can get what they need? Getting to that place starts with understanding the customer and understanding what their expectations are. The you can start delivering to them in the way the patients expect us to.

Erler: Within our organization, there’s an internal cultural shift to start thinking about a patient as being a customer. There was a feeling of insensitivity around calling a patient a customer or treating this more as consumerism, but that’s what it’s becoming.

As that culture shifts and we think more about consumerism and CRM, it’s going to enhance the patients’ experience. But we have to think about it differently because there’s the risk when you say “consumerism” that it’s all about the money, and that all we care about is money. That’s not what it is. It’s a component, but it’s about the full patient experience. CRM tools are going to be crucial for us in order to get to that next level.

Gardner: Again, Julie, it seems to me that if you can solve this on the financial side of things, you’ve set up the opportunity -- a platform approach, and even a culture - to take on the larger digital experience of the patient. How close are we on the financial side when it comes to a single view approach?

Data to predict patient behavior, experience 

Gerdeman: From a financial perspective, we are down that path. We have definitely made strides in achieving technology and digital access for financial. That is just one component of a broader technology ecosystem that will have a bigger return on investment (ROI) for providers. That ROI then impacts revenue cycles, not just the backend financials but all the way to the post-experience for a patient. I believe financial is one component, and technology is an enabler.

One of the things that we’re really passionate about at HealthPay24 is the predictive capability of understanding the patient. And what I mean by that is the predictive analytics and the data that you already have -- potentially in a CRM, maybe not – can be an indicator of patient behavior and what could be provided. And that will further drive in ROI by using predictive capabilities, better results, and ultimately a much better patient experience.

Gardner: On this question of ROI, Laura, how do you at Northwell make the argument of making investments and getting recurring payoffs? How do you create a virtuous adoption cycle benefit?
Gain a Detailed Look at Patient
Financial Engagement Strategies
Semlies: We first started our digital patient experience improvements about 18 months ago, and that was probably late compared to some of our competitors, and certainly compared to other industries.

But part of the reason we did was because we knew that within the next 2 to 3 years, patients were going to bring their expectations from other industries to healthcare. We knew that that was going to happen. In a competitive market like New York, where I live and work, if we didn’t start to evolve and build sophisticated advanced experiences from a digital perspective, we would not have that differentiation and we would lose to competitors who had focused on that.

The hard part for the industry right now is that in healthcare, relationships with a provider and a patient are not enough anymore. We have to focus on the total experience. That was the first driver, but we also have to be cognizant of what we take in from a reimbursement perspective and what we put out in terms of investment and innovation.

The question of ROI is important. Where does the investment come from? It doesn’t come from digital itself. But it does come from the opportunities that digital creates for us. That can be from the access tools that create the capacity to invite patients that wouldn’t ordinarily have selected Northwell to become new patients. It can mean in-house patients who previously didn’t choose Northwell for their follow-up care and make it easy for them to do so and then we retain them.

The questions of ROI is important. Where does the investment come from? It doesn't come from digital itself. It comes from the opportunities that digital creates for us. We have actually increased collections and decreased bad debts.
It means avoiding leakage into the payment space when we get to things like accelerating cash because it’s easy. You just click a button at the point of getting a bill and pay the bill. Now I have accelerated the cashflow. Maybe we can help pay more than one bill at a time, whereas previously they maybe didn’t even understand why there was more than one bill. So we have actually increased collections and decreased bad debts.

Those are the functions that we are going to see ROI in, not digital itself. And so, the conversation is a tricky one because I run the service line of digital and I have to partner with every one of my business associates and leaders to make sure that they are accounting for and helping give credit to the applications and the tools that we’re building so the ROI and the investment can continue. And so, it makes the conversation a little bit harder, but it certainly has to be there.

Gardner: Let’s take a look to the future. When you have set up the digital systems, have that adoption cycle, and can produce ROI appreciation, you are also setting the stage for having a lot more data to look at, to analyze, and to reapply those insights back into those earlier investments and processes.

What does the future hold and what would you like to see things like analytics provide?

https://www.healthpay24.com/

Erler: From a treasury perspective, just taking out how cumbersome it is on the back end to handle all these different payment channels [would be an improvement]. If we could marry all of these systems together on the back end and deliver that to the patient to collect one payment and automate that process – then we are going to see an ROI no matter what.

When it comes to the digital experience, we can make something look really great on the front end, but the key is not burdening our resources on the back end and to make that a true digital experience.

Then we can give customer service to our patients and the tools that they need to get to that data right away. Having all that data in one place and being able to do those analytics [are key]. Right now, we have all these different merchant accounts. How do you pull all of that together and look at the span and how much you are collecting and what your revenue is? It’s virtually impossible now to pull all that together in one place on the back end.

Gardner: Julie, data and analytics are driving more of the strategic thinking about how to do IT systems. Where do you see it going? What will be some of the earlier payoffs from doing analytics properly in a healthcare payer-provider environment?

The analytics advantage 

Gerdeman: We are just starting to do this with several of our customers, where we are taking data and analyzing the financials. That can be from the discount programs they are currently offering patients, or for the payment plans they’re tying to collection results.  We’re looking at the demographics behind each of those, and how it could be shifted in a way that they are able to collect more while providing a better experience.

Our vision is this: The provider knows the patient so well that in anticipation they are getting the financial offer that best supports their needs. I think we are in such an interesting time right now in healthcare. What happens now when I take my children to a doctor’s appointment is going to look and feel so different when they take their children to an appointment.

https://www.healthpay24.com/
We are seeing just the beginnings of the text reminders, the digital engagement, you have an appointment, have you thought about this? They will be walking around and it’s going to be so incorporated in their lives -- like Instagram that they are on all the time.

I can’t wait to see when they are taking their children -- or not, right? Maybe they are going to be doing things much more virtually and digitally than we are with our own children. To me there will be broad cultural changes from how more data will be enabling us. It is very exciting.

Gardner: Laura, where do you see the digital experience potential going for healthcare?

Automation assists prevention 

Semlies: Automation is key to the functions that we do. We expend energy in people and resources that we could be using automation for. Data is key to helping us pick the right things to automate. The second is anticipation and being able to understand where the patient is and what the next step should be. Being able to predict and personalize is the next step. Data is obviously a critical component that’s going to help you do that.
Gain a Detailed Look at Patient
Financial Engagement Strategies
The last piece is that prevention over time is going to be the name of the game. Healthcare will look very different tomorrow than today. You will see new models pop up that are very much moving the needle in terms of how we collect information about a person, what’s going on inside of their body, and then being able to predict what is going to happen next.

We will be able to take action to avert or prevent things from happening. Our entire model of how we treat wellness is going to shift. What primary care looks like is going to be different, and analytics is at the core of all of that -- whether you’re talking about it from an artificial intelligence (AI) perspective, it’s all the same thing.

Our entire model of how we treat wellness is going to shift. What primary care looks like is going to be different, and analytics is at the core of all of that. But most doctors aren't getting that kind of information today because we don't have a great way of sharing patient-generated health data yet.
Did you get the data on the right thing to measure? Are you looking at it? Do you have the tools to be able to signal when something is going off? And is that signal in the right voice to the person who needs to consume that? Is it at the right time so that you can actually avert it?

When I use my Fitbit, it understands that my heart rate is up. It’s anticipating that it’s because I’m exercising. It asks me that, and it asks me in a voice that I understand and I can respond to.

But most doctors aren’t getting that same kind of information today because we don’t have a great way of sharing patient-generated health data yet. It just comes in as a lot of noise. So how do we take all of that data?


We need to package it and bring it to the right person at the right moment and in the right voice. Then it can be used to make things preventable. It can actually drive an outcome. That to me is the magic of where we can go. We are not there yet, but I think that’s where we have to go.

Monday, December 16, 2019

How agile Enterprise Architecture builds agile business advantage

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

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

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

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

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

Here are some excerpts:

Gardner: Mats, what trends are driving the choice and motivation behind a career in EA? What are some of the motivations these days that are driving people into this very important role?
Gejnevall
Gejnevall: Most people are going into EA because they want to have a holistic view of the problem at hand. I do think that EA is a mindset that you can use to apply to any type of issue or problem you have. You look at an issue from many different perspectives and try to understand the fit between the issue or the problem and potential solutions.

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

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


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

EA’s holistic point of view

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

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

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

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

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

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

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

Change your mind for enterprise agility

Wrześniewski:
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.

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.