The combined pressures of Digital Transformation, Agility @ Scale and advances in AI, DevOps, IoT are creating a rapid rate of change for customers and employees. To dig into this topic and its impact on enterprise, business, and solution architecture, IASA Global recently brought together thought leaders in “The Argument: Past, Present and Future of Enterprise Architecture” webinar.
About the panelists:
Michael Sioufas is Director of Enterprise Architecture at McKinsey & Co. He has been in Information Technology for 35 years, 30 of those with McKinsey. Most recently he has spent the last six years on EA, “helping internal product teams address the business needs that we face every day.”
Gordon Cooper is Director of Services and Customer Success for MEGA North America. Gordon has worked in EA and GRC for 30 years. “The best thing about my position is I get to see what many companies are doing and share that with other companies.”
Paul Preiss is Founder and President of IASA Global and hosts The Argument webinar series. “These are my favorite kinds of panels because we have someone who lives with their enterprise architecture, and then we also have someone who has visibility into EA at an industry level across multiple companies.”
This article will dive deeper into a few questions that were discussed. For more of the conversation, please visit the webinar link above.
What does modern EA look like and how has it changed over the last decade?
Gordon kicks off the answer with, “What I’m seeing is the shift away from EA being a (technical) discipline, it’s been kind of removed from IT. Yet technology runs everything. Businesses can not operate without technology. But technology is not what most companies do. EA has become more the gestalt model. It’s a pattern (that contains) more than technology. The enterprise has become more than the sum of all the component parts put together.”
Mike adds, “I’ve seen EA move away from the old notion of the enforcers of compliance and frameworks and more towards enablers that help business units achieve their goals. There’s a move away from standards and frameworks, less ivory tower, to more hands-on design and development work. We’re not getting into details of the technical architecture or the implementation, but we’re working hand-in-hand with product teams to ensure greater alignment and promoting the idea of re-use and standardization.”
“That’s a really exciting development,” says Paul. “We’ve heard so much for so long about EA and the ivory tower, and then we saw a few years ago the pressure from the Agile and digital transformations and pushing architects into a different space. Mike, how closely do you work with business and solution architects?”
“I work closely with solution architects, technologists, and business unit leaders on a daily basis understanding their needs and driving to conclusion on certain big issues or concerns,” adds Mike. “We need to think about the strategic levels/areas that we should focus on and make sure it is included in product development whether that’s cyber controls or greater emphasis on design. It’s more about facilitating the architecture and being a guide or coach, rather than enforcing it.”
Gordon closes out the question with a broader view, “EA is providing the ‘why’ not just the ‘how.’ The new word is composability. EA is not just about providing patterns for re-use or those building blocks. They’re providing the strategic value behind it – the ‘why.’ Now people are looking at (these) things as a way to show how to improve the business.”
How enterprising should architects be?
“EA actually is a way of life. It’s a discipline, a job, a calling, a perspective,” states Gordon. “To quote Zachman, an enterprise is what you do to make money. The whole philosophy, that is stigmatized, is that architects are back in the back room and they’re doing all these cool diagrams and these big spaghetti bowl looking things. And people think these guys must really be smart, but then they realize they can’t do anything with it. The reality is that architects can provide graphical representations of a transformation roadmap. We can tell you what surprises you’re going to encounter and help you architect the surprises out. I think that’s why people need the Enterprise Architect in the room.”
Mike adds, “It goes back to the skills discussion and the ability to communicate to a wider audience regarding how the organization is run based on people, process, data, and technologies. Architects’ value is in showing where the gaps are, identifying efficiencies and then introducing new ways of doing things. I like the notion of domain architects that focus on certain areas of an organization and simplifying that environment focusing on areas that have been challenging or problematic over the years. With enough people supporting a framework that helps to measure, identify, and address it, is one way of reducing complexity.”
“I am seeing other companies doing the same thing,” says Gordon. I’ve heard some people call it micro or macro target operating models where they take a sub-set of the business (systems, processes, people) and architect how it operates and create a road map for what it needs to look like.”
Paul jumps in, “You know, I love the way that you guys are talking about this. The domain architect means we may have chief architects of many different things. To me it feels like value stream architecture. Not siloed value streams, but all working towards the same goal.”
“Absolutely,” Mike concludes. “It’s difficult for any one person to understand the innate workings of any given value stream. Working on a specific domain and becoming a strategic partner with that domain allows for stronger relationships and outputs. More broadly, it creates a community of architects that can share ideas, approaches, frameworks and ensure there is a seamlessness across domains.”
As we exit some of the worst parts of COVID, what are the most important trends/work that the modern EA should be focused on?
“I am seeing a heavy focus on resiliency,” says Gordon. “Knowing how everything connects is important, from processes to capabilities to applications to technologies to risk. The concept of murmuration, where you see flocks of birds react to threats or move in unison, is basically a reflection of the ability of your enterprise to adapt to a market change simultaneously. You can do this if everything is connected. If it’s not connected and visible, then it is not resilient.”
“I agree, that’s the new norm” adds Mike. “Adaptability needs to be in everything that we do. We’re going to see less reliance on the way it’s always been done. Being able to change depending as situations occur is essential. Information technology is all about evolving and needs to be even more so post COVID.”
Paul adds, “I had a very good friend of mine once say to me, ‘what I need in my architecture is flexibility. I need to be able to go buy a company or I need to be able to go sell off a portion of my company.’ This is something that I’ve said for some time, the ability for enterprise architects to create reference architectures that establish a pattern and use that as building blocks. We need to think where does the business want to be? Where is the business going that brings the most value to customers? It’s going to be when you’re evaluating emerging technologies or disruptive technologies.”
“I think enterprise architects should be working hand-in-hand with the business and helping to guide and identify opportunities as much as possible,” says Mike. “I think going forward, we’ll find there is no constant partnership. We talked about the business and identifying where it should be going and how architects can help facilitate these strategies. For 20 years or so, we’ve been referring to the business as the experts: they give us the requirements and we go build things. When does it become, to the point where we’re driving business cases ourselves? And we’re saying, ‘We need IoT devices here or we’re going to need an Alexa skill there.’ When do we get to come out of the closet, so to speak, and start being the business, where every company becomes a technology company?”
Paul summarizes the discussion with, “It’s a provocative question in multiple ways. I think enterprise architects will partner, and continue to work with the business, and be part of the business. Perhaps that is what’s missing…that enterprise architecture shouldn’t be considered a distinct group, or a distinct function or distinct offshoot of technology. I think architects should be part of business units and working with them.”
To hear more, click on this link: “The Argument: Past, Present and Future of Enterprise Architecture.”