View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Courtesy of MEGA International's Dan Hebda's below is a transcript of his speaking session on 'Using composability to drive flexibility, speed, and resilience' to Build a Thriving Enterprise that took place at Enterprise Architecture Live.
Session Information:Using composability to drive flexibility, speed, and resilience
One lasting learning from the past year is that businesses that we're able to pivot quickly could accelerate investment and strengthen their resiliency. Pivoting quickly is made possible by having a composable business made from interchangeable building blocks.
Imagine being able to take apart a spaceship and rebuild it as a castle using the same building blocks, or more relevantly, take apart a dishwasher and rebuild it as a ventilator. Enterprise architects are the ideal people to lead this effort given the knowledge already derived from architecting the enterprise. In this session, you’ll learn how enterprise architects can be key contributors to composable thinking using modular thinking and applying it to business and technology capabilities.
Watching for Dan Hueber.
So for over 20 years, Dan has been at the forefront of technology innovation that helps businesses meet their strategic goals.
In his current position as Chief Strategy Officer for Mega, one of our sponsors, Dan Drives the company's strategy focusing on formulating product direction that meets evolving market needs for business transformation, and software solutions.
He's worked closely with the Fortune 100 companies for many years, providing advice and direction on business transformation, and innovation from the perspective of enterprise architecture, and change management.
So, without further ado, Dan, where are you?
Hey, Chris. Thanks for the introduction.
There is Dan. Dan, I'm going to fade away here and let you take over the presentation and I'll be drawing you back. When it comes time for Q and A Everyone, please put your questions in the question box, if you'd like me to get those to Dan. As always, I have my own questions for Dan, but I would much rather ask yours if you gotta take care. And so, take it away to thanks.
Thanks, everybody, and welcome to the session today. I am going to talk about a topic that's very near and dear to my heart, and that would be the value of enterprise architecture. And whether your architecture practice does deliver real business value. That doesn't mean it can't be IT oriented in nature, but we'll speak to how I connect the dots here in just a moment. So, first, anytime I speak to value for a particular organization, in the context of Enterprise Architecture, I like to ask the question of who is the value for?
And for me, this is important, because delivering value is more than just the delivery itself, but it's the recognition of how you're going to measure that value and get credit for that value, so that the practice, as a whole, is seen as something that the organization benefits from. So, as we talk about who the values for, we have an approach at mega that we describe as noisy to influential. And this is really taking an extroverted view of the perspective of the value offer.
Too many times, I run into architects, and I'll ask them about their practice, and they might mentioned something about their maturity, maybe about the number of resources they have, the credentials of those resources, the frameworks and number of models created.
But if we then go to one of their stakeholders, and say, How valuable do you see that practice as I get a different story.
We actually ran this as a single question survey at a conference recently, and we asked attendees, how would your architecture practice be viewed, noisy, useful, trusted, or influential.
And as the majority went to push, either trusted or influentials the answer, we said, but one caveat.
The answer should be in the perspective of your stakeholders, or the business.
And all of a sudden, the shifted left towards noisy. So let me give a little bit of explanation on the spectrum and how it can work to help you identify value. And then I'll use a modern example, today of architecture, working with modern software development practices to show how we can illustrate that.
Noisiest, when a practice is new, maybe the organization isn't fully aware of what the practice can deliver, why it exists. Maybe they're not even familiar with enterprise architecture. And so we start, there is a default, if it's a new practice, and were unfamiliar the stakeholders in those in the business, just see it as, I don't know what it is. It's kind of noise.
And we very quickly want to move to useful. And you can't skip this step. by the way, It's an important point. You must first attain usefulness before we can get the trusted or influential.
And this starts by identifying a number of stakeholders who are willing to take some of the work product that we can produce that we'll push to them and show them the value of the visibility that architecture can provide.
So, we want to get quickly to this push mode status, achieve a usefulness.
Then from there, we want to evangelize the architectural practice, and we're hopefully going to do that in conjunction with those stakeholders, to say, Hey, if we delivered real value, measurable, concrete value to your business, your business line, to whatever you might view it as, Would you mind, may be mentioning us to some of the other organizations, how we can help them, as well. And we find that this creates somewhat of a viral effect. Once you prove value to some element of your organization, the word does spread, and other elements of the organization will come to you for help when they face similar problems.
This is where it's poll mode. When they're coming to you asking for help, and assistance and additional information, you've become trusted. You've expanded on the number of stakeholders, and you've achieved that tier.
Then from there, we want to continue to say, OK, but it's not only after decisions are made or after problems occur, that you should come to us, and maybe pull or ask for assistance. But really, let's shifted left. And at the very beginning of the conversation, let's discuss how we can provide assistance, visibility, and help, and at that point, is where it's collaborative mode, and you're, but you've become influential. So I do like to keep this in mind anytime we're discussing value in the context of enterprise architecture. And if you take anything away, it's really assess the measurement of your value from the lens or the eyes of those outside of the practice. Alright, so let's take that now from the fully academic and kind of bring it down in different levels to more granular, more concrete examples.
To start with the articulation of a vision. There's a famous story that goes that. John F Kennedy visits, NASA. As he's touring the facility encounters a man with a broom.
He asked, Semenya, What are you doing are, in essence, what do you do here? And the reply was, Well, mister President. I'm helped me put a man on the moon.
And the reason why this story is so interesting, because it highlights the uniformity and the clarity of vision, Mission purpose that existed, such that every member of the team was rowing in the same direction for the same goal for the same outcome.
Now, I may articulate that in the context of putting men on the moon and NASA, there was a massive singular focus for that achievement.
So, to some extent, getting alignment, at least of understanding, is easy compared to a modern complex organization. Maybe has many different directions, and elements to its strategy. But the point is still important that we get to this level of clarity, of understanding, so that we can move and transform in the same direction. And this is especially critically important today, as it relates to the speed of change and the amount of disruption that occurs.
So I use this as an example, if we have a number of business lines and business units that exist throughout a complex organization, which, by the way, is, in essence, every organization today. And we have the different job titles that we've got here, the senior vice President, Vice President Directors, but you can put all of the job titles here that cut across the different business lines.
You might look and say that as we articulate our strategy and we communicate that vision, that it's going to cover the entirety of the organization, like a nice blanket, that everybody will have this common understanding this cohesive vision on where the company is going.
The problem is, it doesn't typically work that way. I recently entertained a roundtable discussion at a previous event just the number of weeks ago And an individual had used this example I thought was very illustrative for today's conversation.
Instead of the strategy and vision overlaying the organization like a comfortable blanket, that dissection of business line business unit and job title results in cross cut shredding the strategy.
Resulting where there's little pieces of information spread throughout the organization, with, with not many people having a real, large, cohesive understanding of the impact of their piece of the bigger picture.
And that's what we're going to use Enterprise Architecture to help fulfill in order to deliver on value for the organization.
So I've been working on evangelizing a different way of looking at Enterprise Architecture.
What's the purpose of the practice? Not, what's the deliverables. Not, what's the method, or the frameworks, or the certifications? But what is the purpose of the practice? And again, primarily as viewed from those outside of the practice itself.
And so, I've got a couple of working models here.
one, aline enterprise execution, the operating model, by design to the company strategy.
So if I imagine that there is this strategy and this vision that exists, and we have the current state and how it operates, we're going to use architecture to design a future state that brings us into alignment with the strategy.
We could put it differently and say we continuously align the strategy and operations, and the reason I put that caveat for the difference is that while the major priority is to bring operations into alignment with the strategy, there are cases where, in doing so, you recognize that there's an element of the strategy that's just not possible, either with current resources, current timeline, whatever it might be.
And it may justify that the strategy itself has to be edited or modified to bring it to an actionable and a realistic level and perspective.
Alright? So let's step it down. again, putting a little bit more granularity, a little bit more clarity, and use the example of enterprise architects, working with modern software development teams. This is a question I get all the time. As, as the modern world with technology is just faster, and faster and faster, and software development has gone to continuous development, continuous delivery, it's, it's all moving in an Agile way, people are pivoting. Does architecture still have a place?
Is there still value from architecture? So, let's step through how we can show that. Yes, there absolutely is. And I'll start with a little bit of humor. I borrowed these slides from my colleague, where we want to understand first the perspectives at which the different audiences or individuals are coming from.
So, if I look at the software teams, these modern software teams, how do they see themselves?
Well, maybe hip, trendy, they'd be cutting edge forefront.
And I think there's some truth to that.
he modern software development teams are keeping up with all the modern customer experience expectations, leveraging all of the modern technologies that are coming up every day. And so there is sort of a coolness to the work they do. There's an importance to the work they do. And for sure there's there's an element of training is to it. But maybe the illustration here is a bit overstated as to just how trendy they might want to see themselves.
Well, how did the Architects' see that same team?
Well, maybe not quite so trendy and cutting edge. Maybe a little bit.
This, dysfunctional, maybe a little bit less sophisticated, maybe that's a better word. So, they are moving, They are moving in this case and in the same direction. But maybe not with that same element of style and cutting-edge element as they profess they have themselves.
But how about the flip side?
How did the architects' see themselves?
Maybe as they're holding the world on their shoulders, and their foundational architecture is underpinning the organization making it operate. Without them, the world would collapse.
Perhaps a little bit overstated. There is an important ... architecture, of course, but maybe overstated, but how did the software teams see the architects?
Well, in case it's not clear, the image, the architects would be the boot in this photo.
And too often, the architects are seen as an organization that is hung up on the phrase, no, there were seen as the group, that says you can't do this.
You mustn't go that way, you're not allowed to do that thing. And that's where the problem comes into for the value recognition.
In the case of the modern software teams with enterprise architecture, we need to change this, in order to change this, we need to understand that the perspectives are not quite as opposed as they appear. So if we look at the way I described the recent examples, it looks like they're completely at odds with each other.
There's this modern Agile software development team, looking to go in one direction. Let's say, the high speed direction, and there's that enterprise architecture team, trying to slow them down or get in the way. that's the perspective.
The reality is that we're all moving to the same target, and if we just adjust our perspective a little bit, we can see what was perceived to be an antagonistic relationship. If you will. one that does not work well together is actually one where it should be in conjunction, working in the same direction toward the same target.
So again, I'm going to drill it down just a few more here, and speak to some of the examples of how we can illustrate this.
So let's put some context to that different perspectives, and show how we can clarify where these different groups can work together.
I'm gonna use, in this case, a sports analogy. We'll start with the notion of the ambition of the modern software individual. Will get one player on a field.
They must be Agile.
They're gonna run fast. They have to pivot where appropriate. And they have a goal in mind in this example to score.
And so in this case, I could understand that if I am that Agile player representing the software and the modern software development team, I would absolutely not expect anybody who was on my same team working for my same organization to jump in the way and stop me from creating progress.
That is a perspective that to some cases been earned by architects where too often they had an academic or an ivory tower based approach where they might dictate standards and be a little bit inflexible to the needs of the current pivots and the accelerated development.
So we have to be sure that we don't get in the way but if we're not getting in the way and we're not taking academic approach, what is the role of the architect?
Sticking with the sport analogy? The architect's focus is on adaptability. This is ensuring that the entire organization, not just the singular player, is able to move in a fashion that is agile, but it's also in line with the organization's goals in total.
So each individual player perhaps wants to score, they want to achieve their singular outcome, an expectation.
But first, there needs to be clarity of the guardrails to the particular game. What is the boundary of the field? What is the rules of the game?
And then there needs to be visibility into, what are the teams that we're facing, what are their strengths and weaknesses, what is the season look like?
In this way, we can plan for not only achieving a singular goal of a single player, which is important, but also achieving the victory of each game.
Weekend, week, out, season long, year, in, year out, to stay a leader ahead of the organization.
So it really is a co-operative and collaborative relationship that exists between the enterprise architecture teams and the software development teams. They should work together. And you can see here, again, using the analogy, if that players running down the field, they would not expect one of the coaches from the sideline to jump on the field.
And tackle them, or stop them from achieving their goal.
But, they would expect that they'd be given the materials and the information, the practice, the training, even the equipment that they need in advance of the game, so that they can make the right pivots at the right time, at the speed that they need to do so.
Now, in prepping for this presentation, I was reviewing some of the modern software methods. It's a little bit of an old video. It goes back probably about eight or so years ago, but the Spotify method. And in the video, they highlight this: matrix view alignment versus autonomy plotted on a graph.
And I thought this is very illustrative of the relationship, and the reason I include it in the presentation is this is coming from the software development perspective.
This is not a slide created by architects, but rather by the software teams.
And so, we want high alignment and autonomy.
We need the coaches and the players. And you can see it's depicted here as two different roles.
one section that says, this, the problem statement, right, we need to cross the river, but I need help from software development team, to figure out how, as the architect, I need to establish, the higher level goals, the business outcomes that we're looking to achieve.
And I need to work in conjunction with software development teams to ensure they have all that they need to succeed in their goals, so that we get the outcome that we're looking for.
So does that mean indicated that the enterprise architects are in charge?
The Spotify graphic, probably the individual setting, the vision and tone, was a boss or manager, and equating that to the architect.
No, and this is critically important. We are all on the same team. The vision and the direction comes from the executives, the board, those in charge of establishing the strategy for the organization.
The architects have a role in helping to clarify and organize that vision into an actionable set of details.
That can help clarify for the fast moving software development teams to really achieve their goals. So, please, if you are an Enterprise architect, be very cognizant of this. There cannot be an arrogance or an academic approach, it will not work. What you do need to do is find a way to collaborate, where there's genuine accountability for your architectural work, in the achievement of the actual outcomes.
So borrowing this slide from infotech, they put it on a continuum. And you can see at the very far left, if I fully separate enterprise architecture, which is maybe the historical mistake that's been made, it's then seen as an ivory tower approach to segment.
It's where that group can say, I'm going to dictate. these are the technologies. These are the standards and I expect all to use them.
Independent of any problems or challenges they might face independent of any modern shift in the marketplace or disruption that they're having to address, it doesn't work.
If we swing the pendulum too far the other way and we split it into fully decentralized, then we can get the accountability the architecture. But it's not really a centralized architecture practice anymore.
And so the benefit of leveraging best practices, lessons learned, foundational elements that we'll speak to in just a moment, it gets weekend, if not lost, if we swing too far to the right.
But if we sit in the middle here, where we have an enterprise architecture practice that does have accountability in the outcomes that each of the business units in this example require, or, in my example, the software development teams, but still has a vision that cuts across the entire to the enterprise, then we can leverage best practices. We can establish foundational architectural elements, and we can still ensure that when there's a need to pivot.
And the architecture team, working with the software development team learns of a problem, that instead of saying, no, this is the standard, you're stuck with it, they would say, well, let me help you find an alternative.
Let's work together to find a new way to achieve the outcome that we're all striving to achieve.
And the architects' take on the architectural perspective of achieving that all come with, software developers, stay focused on their tasks at their speed.
So, if I use safe, as an example, scaled, agile framework here. You can see kind of the difference in the perspective. If I look at the enterprise architecture role, it's cutting across all of the different value streams.
You've got a solution architect in the middle, that maybe looks across different systems, and the system architect, and or the software development team is going to be focused more frequently, on a singular system.
Doesn't mean they're constrained that in today's modern world, but just for the sake of the separation of duties, if you will, the architect is cutting across value streams. This is critical, and this is important.
So for those who may not be familiar with the concept of a value stream, value stream is a concept we put the send, the customer at the center. And we're looking at all of the value oriented steps that need to occur in order to deliver that value completely to the customer.
And so you can see here, one of the problems it looks to address, is that business leaders may see development as a black box.
Maybe they can't track and follow exactly what's going on in that development cycle, is it on track to help us achieve the strategic vision, many business leaders can't tell.
Also, was a quote from a previous set of presentations.
I'd, given a preceding presenter before my own, had commented that if the software development function and practice becomes singularly a cost element, where there's no understanding of value, purpose, and direction, you're at high risk.
Because there are elements where the software development is required, and it may have a cost attributed to it.
And there are other elements where maybe there's an accepted high level of spend, and isn't necessary to opening up that black box in a meaningful way.
To business leaders, value streams can play a role and help here, And similarly, the development teams themselves are often left in the dark.
If they're looking at that notion, saying, I need to pivot. I need to pivot rapidly, I need to deliver on certain outcomes in a way that achieves the strategic goals of the organization.
But maybe I don't fully comprehend the strategical Z organization, Or maybe I don't fully understand how my function, the development I'm working on right now, how it connects back up to that strategic vision.
And so, we're going to use this example of the value stream concept.
We're going to articulate and this the arrows here, the value stream stages. These are the elements that are going to go through each one delivering value, and then underpinning those.
We're going to identify the business capabilities that are needed to support those value streams in their current.
And it's going to be this relationship that we're going to use to help provide a basis for clarity to act and a coaching capacity, to create visibility within the organization. So we can understand how to communicate and drive cohesive transformation at the speed that the market dictates.
So if I look here from a quote, quick Gardner method, right, we're going to start with the identification of the customer.
We're going to look at the steps, we typically call those the value stages.
We're gonna look at those supporting capabilities that illustrated on the previous slide.
Then, we're going to try to understand where there's gaps.
Where are we falling short on the value? we deliver the customer in the context of the organization strategy?
So value streams, socialized knowledge across functional silos of how business capabilities interact to drive value to customers, key important point.
Where are they going to take the result of those particular value streams will take it further.
We're now going to start mapping some of the architectural elements, the applications, the processes, generically, the people, process, and technology, to understand how those different capabilities are fulfilled in support of the different value stages of the value stream.
We're then going to determine, are we functionally aligned?
Are we delivering what's needed to match that customer expectation? Again, in line with the current strategy and vision?
If we see gaps, we're going to plan for transformations. So you can see, again, the value stream provides insight and a lens into how underlying applications, information, and technologies support the end to end value stream activities, In other words, support the end to end delivery of value to the customer.
So we're doing this, using value streams with underpinning capabilities to clarify specific business outcomes that are necessary to achieve the strategy.
So, we may not get to that full blanket, covering everybody that has a complete understanding of the breadth and depth of the entirety of the strategy, but what we will minimally do is articulate specific business outcomes that, if achieved, will result in a successful strategy, that give us enough clarity. So that in my example today, the software development teams, but it can be also, any kind of business transformation, it can be operational excellence. It's all sorts of elements here.
Any transformative aspect can be executed, understanding enough of the purpose of their transformation, so that, when they pivot, when they have decisions to make, when their options on the table, they can reconcile it, resolve it back to this business outcome, and its achievement.
Knowing that the business outcomes have been defined and articulated in the way, that, again, if successful, will result in a successful strategy.
For those who might not know what a business capability is, I have a separate presentation on the topic. I'm going to give the very short view today. I do put my contact information at the end of the presentation, So if you're interested, I'm very happy to follow up with you. But in essence, the power of the capability underpinning the value stream is that business capabilities are very stable and they last a long time.
So in this example, I use a human example, the ability to walk.
And so you can see that there's an introduction of a new capability to point in time. Maybe that's toddler. That capability will be sustained through adolescence, adulthood into being an elder, et cetera.
But changes, though, is the way you can measure the result of that capability.
In bringing it back to business example, the implementation that people process and technology underpinning the different capabilities may change over time, as a matter of fact, will change over time.
So while the capability itself is very stable and allows us a communication element that we can put measurable aspects against, the implementation can change, which will result in a different measurable outcome.
So in this example I use here, if we're looking at this ability to walk, it's sustained for a very long time, but if I were to put some metrics like speed, stamina and stability against that metric, I would say that the toddler probably has excessive stamina.
Lower speed just due to size, and stability may be a little off as you get to adolescents and adult. You might maximize maybe your stamina drops a bit, but the others get maximized.
Then as you move towards elder, maybe all of them start to decline a bit.
I will admit, I've been sitting on the couch for the last two years during ..., but, if I were to entertain moving into achieve the completion of a marathon, I would need to work on my stamina. Perhaps my stability.
And I would then be able to co-ordinate with teams, to say: I need to adjust my diet, my strength, my equipment, in line with achieving that goal, which is the completion of the marathon.
If I generically asked for advice or direction about health or fitness, it may not support achievement of a marathon.
And so clarifying that to the group who's going to help provide the solutions, it's critical for success. So, just to revisit the value stream vision with the underpinning capabilities. I can see here if I'm looking to design new products, test and drive the prototypes, integrate market feedback, et cetera, underpinning that are the different capabilities. And then, underpinning each of the capabilities I can articulate measurements that I could establish as well as targets for those measurements.
The targets for those measurements effectively are the business outcome.
Those can be communicated throughout the organization so that, again, is they're moving at high speed, continuous delivery pivoting when necessary.
They understand the outcomes that they're looking to achieve, So as to not pivot out of alignment with the organization strategy, resulting in a failure instead of a success.
Borrowing a little bit more from safe in this context, you can see some of the value add and positive elements that are included here.
And again, safe comes from that software perspective, So I'm ensuring the organization can take advantage of emerging opportunities.
Positive, value oriented, beneficial statement.
I may offer recommendations for development delivery. Again, it's advisory, it's supportive, then I'm going to put a customer centric mindset in place.
What you won't see in the saved element, nothing here will suggest that the role of the architect is to get in the way, of software development, or of the high speed transformations that are going on in most organizations today.
So if I summarize part of what we've spoken to so far, I split it into two elements: Agility, and adaptability.
Adaptability is the ability to respond to market changes or disruptions. Agility is the actual response itself.
And you can see how we can clarify the enterprise vision, break it down into elements or goals.
That will result in a visualize capability enhancement.
Those are the metrics that we're going to target for future states, so that everybody's on the same page.
They can then be grouped and organize into different phases of transformation.
And, with that visibility, handed off to those responsible for the high speed transformation, and they can pivot and make the changes with guidance and clarity as to the outcomes that they're trying to achieve.
You may opt to give them complete access and visibility to the Enterprise Vision. That might be the ideal. And some organizations that complete Enterprise Vision may be a bit large and may distract from the actual outcomes that their work is directly connected to. In either case, as long as you have the outcome that their work is directly connected to, you can keep everybody in alignment so that the whole team is working together all of the many different projects, not just the individual action.
So coming back to the player on the field, we have to take it now a little bit lower. It's not just about guidance, guardrails, outcomes, et cetera. But it's also about enablement.
Because there was, of course, the element of skin in the game and the business outcome orientation.
But now, we've got, also, that kind of foundational element, how can we support this even further, to enable adaptability, and show value for architecture?
So, first is that we have to enable these modern software teams.
There's going to be technologies and tooling that they require. There's a lot necessary to enable an organization to move in a continuous fashion. And the architects need to ensure that they stay ahead of those needs, Indirect co-ordination with software teams. Again, I don't want to be misunderstood as though the architectural dictate the different technologies used by the software teams, not at all. But when the needs are communicated to the architects, can look across the company and put in place best practices and standards in a beneficial manner, not in a prohibitive manner. And then, working from there, can ensure that every one of the different software teams that's moving forward has what they need, even if they're leveraging different softwares in that context, safe causes the architectural runway. And I like the quote here from Gartner: It's only a runaway if you can use it.
So, that means the design and the forward looking vision is insufficient. The architects need to ensure they have clarity and vision into the project, and the work that are going on in the different software development teams.
And then put an architecture in place, meaning take it from design, all the way to ensure that it's a reality, so that as a software development teams land their projects, their program increments there, different product level workloads, that they're going to have everything they need in place for it to succeed.
So it's really about enablement.
This is a key aspect, again, of the value of architecture.
We're going to use our work product. We're going to use our ability to design to bring operations into alignment with the strategy. And that includes supporting the needs of the different elements of the organization, in this example, the software development team.
So we're looking to enable accelerated delivery, specify and clarify the business outcomes, not get in the way And again, that's where you fall into that academic trap we have to be very careful about.
So here a vision of architecture at different paces.
If we look at the different tiers here, I might call the top level enterprise architecture.
Maybe I break it down to a solution architecture at the next level and bundle them, become different organizations, have a boundary, and a different point, or place.
And then eventually get to the software development teams.
So I've got that slower moving more stable aspect of the business objectives.
The outcomes, as articulated through capabilities aligned to values' dreams, creating a cohesive and easy to understand element that the organization can communicate around, ensuring that we prohibit that schraeder effect.
I'm also going to put in place elements around technology standards and patterns. And again, this isn't a prohibitive standard. This isn't a standards as you can't do.
But it's a standard that says, if you're looking to achieve the following, here are some pre researched, previously deployed, successful examples that you can benefit from, And if that doesn't meet your needs, we're going to work with you to find one that does.
From there, we're going to decompose it into intentional architecture.
Here's what we can start to put together, even things like templates.
Patterns, and these templates and patterns can be scoped with the business capabilities.
Chris mentioned in my introduction, the Lego concept and this is where you can start thinking in the way of Legos.
If we can organize re-usable facets at both the technological and the business level, we can then bring it together so that we can easily assemble different solutions in different parts of the business.
Including, if we imagine new solutions, new business lines, new business models, maybe we can leverage some of the existing aspects in new instances to support this new business vision.
And then we get down to the software development itself, and again, they're moving at speed here.
Very high speed, and as we come through, and we're working on the pivots, we come up with emergent design, we may run into a challenge with the architectural details that have been provided, or the architecture itself, as it's currently deployed.
That's where the reconciliation needs to occur.
And the architects need to be open and amendable with skin in the game to be able to work with those teams to say, here's how we can together, achieve the outcomes and the solutions you're looking for.
So I'll put it in place. Here, the conclusion is that one, we want to unify the organization to have the greater chance of achieving the strategy.
We're going to do this by avoiding the shredder concept and creating an intermediary concept of value streams for business outcomes.
So that we can minimally ensure that anybody who's participating a transformation throughout the organization is able to connect their transformative work, where they need to pivot at high speed, up to an outcome.
So that they have all the information they need to make the best decisions When they are pivoting.
And that they don't pivot out of alignment with the strategy, but rather, into alignment with successful strategic achievement.
We also need to manage the different paces of the transformative work.
There is the higher level slow moving. That's the business model perspective, capability evolution. These are a little bit longer term. But they can be used as the basis to understand and measure where there are gaps in the market fulfillment and customer expectation. or even just internal expectation. If we want to operate a higher performance. And we're not, maybe we need to add some level of efficiencies that can be used that tier decomposed to the next tier. Which moves a little bit more frequently. Now we're talking about how we implement those capabilities.
And then again, looking at where the shortfall based on market and our customer as well as internal expectations. By the way, I've sort of glanced over it. But regulatory is another dimension here, as well.
So are we meeting with our regulatory expectations or not?
And then moving that down to the level, where that high speed, modern software team, or, again, modern transformation team of any kind, where they can pivot.
And instead of holding onto the little shred of the paper, they've got clarity through the outcome that can be connected back to the strategy and entirety.
Similarly, we think of the analogy of the sport team. The player must be able to move in an agile manner. We expect all players on the field to be agile, have the ability to pivot, achieve their goals, but there needs to be co-ordination between all those players to have success that that aligns to the strategy.
And that's not just to win the individual game, it's too when the season. That has to win season after season, after season.
And so the Architects' must be supportive and collaborative in that role not combative or academic getting in the way of the practice or function.
So we're there. I think I'm on time, thank you very much for the participation today. And of course as always I look forward to entertaining questions.
Dan that that was absolutely fantastic. And I know that sounds like hyperbole.
So let me make it not sound like hyperbole. Can you hear me OK?
I absolutely can't.
So let me, let me explain what I mean by that.
I don't know the background of everyone listening to the call. I know my background and I've heard some of your background.
And you touched on some of the most important dimensions of why, and how all of this can come together or not. You touched on the people, the psychological side of it. You didn't turn it into a therapy session, but That's incredibly important.
You talked about the power dynamics and the different ways, the levels of, of flexibility and speed.
And, I don't know, anybody who was listening to this, there's no way you can take in everything Dan said.
In a couple of minutes, or 30 minute presentation, it's just impossible. But you just, yeah, of course, fortunately, they go back to the recording and watch part of it.
So I just want to say, you know, being in your space, I've done a bunch of implementation projects, have been involved where all the things that you said could go wrong.
Although, I white Tower. No, and there's only one thing I want to say before I ask you a couple of questions. So that is to add to what you've said. All right.
And this is not your specific practice.
I stumbled onto a book recently that would have saved me, more arguments than I can possibly imagine and friction will hold the book up. Unfortunately, the gold has rubbed off the letters.
It's called The Laws of Human Nature by Robert Greene.
It's the same guy who wrote the 48 laws of power, but he speaks to the human element of what you're talking about, but without what you just laid out, a masterclass on, how to set up the function and make it I'm. So let me bow a difference. OK, now, let me ask you a couple of questions because there are a couple questions.
First one, how can enterprise architecture management assist with AI integration in an organization? I think that's a softball to you. What do you think about that issue? So, that there's a It's It's kind of a broad question, there's a lot of us, aspects that It can play a role, there. So, for me, if I use the basis for the presentation today, but for whoever asked the question, of course, feel free to reach out to me directly from information. I would look that business capabilities are often formed around key business objects within the organization, from a data and information perspective. And so, for me, when I'm looking at AI, I'm looking through where the AI can fit in the organization, the data science, and all that, how it comes together. Unless the question is more about tooling, let me know, maybe I misheard you.
Lyman actually is the person who answered that question. So, alignment and hopefully, come back to you. Put your contact information. That's great. And you can track it.
So, that's perfect. And then you got some very, just some generic, positive, wonderful comments about that. Yeah, This doesn't happen so often that everybody, I think everybody likes these presentations, but not everybody types in the content. So, you're getting some really positive stuff there, as well. I want to thank you for, for the value, you're bringing you both you, and your company to this, to, this session.
Here's an OK, here's a question, Well, how about advice on how, and this goes back to the laws of human nature.
How about advice on how to change the relationship between the Enterprise Architect and the other departments?
If it's already rockey, and you can't answer with buyer, the other guy's. Not too bad. Executive mandate, can I do that one? Can't do that. Now, So, that's a great question. I find the way here is you've got to find common ground for reboot And I think from an architecture perspective, I think architects maybe we need to own some of the problems that have occurred in the past. And so, I've seen too often, they come forward with, Hey, you know what, your side just doesn't see how valuable we are. Instead of saying, You know what, maybe we need to take a step back and say, We were a little bit too restrictive, a little bit to every tower on our approach. Let's show you and demonstrate where we can offer value, and let me listen to you.
Let me really hear what you're trying to achieve, and then I'll revisit how I present back, the value of architecture. So, I think that's one of them, it's gotta be a little bit more open to the possibility that the architects played a role in that relationship riffed, instead of always kind of accusing the other side of being at fault.
You know, when I couldn't agree with that more, when I'm listening to you, I could change a few of the words you're using.
So, let me say, for example, instead of the Enterprise architect, the Lean six Sigma Master Black Belt, how do you start missing off the operations people?
Right, how about respecting everyone has a really important function.
Extend it to actually work together. I love that soccer analogy.
You know, if you figure, it's such a human thing. But what you added was a whole structure and dimension. Because you could just say, learn how to get along with people.
That's nice because it's a little shallow, right? You've got great structure of how, how these various pieces need to function.
But, I agree with you, know, the idea on the question.
If it's a bad relationship, Man, it is 90% people, It's 10% brilliant process and structure and organization.
It's 90%. Do you think the IT guy's a jerk?
Do you think there's Yahoo Or whatever right, The solutions person is a software person.
So much about it. We don't have time for that anymore. So let's all figure out how to get a good question for you. We've got a couple more minutes.
Um, OK, here's, there's another people question, but it's still it's totally wrong.
How do you identify and choose the right stakeholders to work with, OK, So in her essay question, for me, there's a couple of things you look for here when try to identify the different stakeholders. one, it's achievable in terms of the problem statement that there might be facing, and the value you can offer.
You don't want to necessarily bite off more than you can chew, and so if you, if you find a stakeholder who has a massive problem, and it's going to take you years to prove the value, that might not be your best first pursuit of finding a stakeholder.
Yeah, but something Manageable and independent scale of practice maturity of practice This is sort of a newer practice, is maybe a little bit younger trying to find their first. Stakeholders, is don't don't go big or go home and that case, you might find something manageable. And then again, look for common ground is similar to the previous one about rebuilding the relationship. Right you knock on doors. You know, they're not going to come to you. It's noisy Remember, when an ear practice you'll kind of puts their a shingle out and opens up the doors and says, Here I am. It's not always clear to the organization what that means and what the benefit is. So you're gonna have to go market a little bit, go knock on some doors. Talk about what you offer. I suggest a practice's articulate, and some of us have borrowed from soil brand over at Gartner, EA's Internal Merge, EA's internal management Consultancy, defined some of the services you can offer.
So you can go out and market it, and just say, I'm here on EA, and I'm here for you, OK. What does that mean?
Go and talk about, say, Hey, you know what, I can give you visibility. I can, and, these are very broad example, it'd be more specific and in actual practice, but you can talk about the things you do for the organization.
Knock on some doors, find someone who's common ground, Illustrate the value once you illustrate it. Again, that's the viral effect.
The second set of stakeholders are much easier to find once you have the Asheville for A set, yeah, No.
I attend these sessions a lot and I learn something every time.
But I, I think my, it sounds like a Hallmark card or something but like my heart warms, when I hear people resonating with the technology that people and just understanding how complicated we are and recognizing it because that's what's gonna make it work, right.
You think back to your most successful projects and most successful things, that's what happened, it was the combination. So, look for me, my personal perspective, this has been an absolute pleasure. I get to selfishly ask you whatever I want to ask you. Well, I'm going to try to Workday and all the other questions I got.
So, Dan, I want to thank you and your company, company for being here on the, on the presentation for today.
I don't know if you're gonna join in the rest of the sessions, but mega has been very helpful for sponsoring the project, and I'm sure we'll hear a lot of comments about what you've said. And I already there are people asking me, you know, Can you get the presentation?
Yes, yes, you'll get the presentation, but what I'd say to anybody is, study that, and take advantage of Dan. He says, He'll answer your e-mail. Well, that doesn't have it all out of it. So it's great to take advantage of data. That's the idea. Get the message. So, Dan, thank you very much for your time, everybody. We will be back at the top of the hour with one more presentation for today, before I do a wrap up. Now, it's going to be coming to us from Walgreens and Olu, yummy .... We're going to talk about how over yummy ... should write a book because that is a fantastic author's name.
He's going to talk to us about what has changed in Enterprise Architecture post pandemic.
Isn't it wonderful? You can say post pandemic because we're almost there anyway. We'll see you at the top of the hour. Thank you. Very much. Take care, everybody.
Chief Strategy Officer,
For over 20 years, Dan Hebda has been at the forefront of technology innovation that helps businesses meet their strategic goals. In his current position as Chief Strategy Officer for MEGA International, he drives the company’s strategy, focusing on formulating product direction that meets evolving market needs for business transformation software solutions.
Dan has led many complex programs in business transformation, from the perspective of enterprise architecture and change management. Through his expertise, he helps organizations begin projects faster and deliver ROI sooner. His background in business architecture, process analysis, technical architecture, application integration, and product customization has helped him guide companies in their strategic initiatives and use enterprise architecture to produce valuable business outcomes.
Search for anything
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Watch On-Demand Recording - Access all sessions from progressive thought leaders free of charge from our industry leading virtual conferences.Watch On-Demand Recordings For Free
Courtesy of Nintex Pty's Paul Hsu, below is a transcript of his speaking session on 'Improve employee productivity during and post-COVID by ...
Read this article about HP, Best Achievement in Operational Excellence to deliver Digital Transformation, selected by the independent judging panel, ...
Read this article about BMO Financial Group, one of our finalists, in the category Best Achievement in Operational Excellence to deliver Digital ...
Read this article about Cisco, one of our finalists, in the category Best Achievement of Operational Excellence in Internet, Education, Media & ...
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events