After sharing the discussion on the evolution and perceived value of enterprise architecture and the ability for EA to align Business and Technology, let’s explore what our thought leaders, President of JV Strategic Solutions John Varricchio, KPMG Enterprise Architecture Leader Roland Woldt, and MEGA’s own Chief Strategy Officer Dan Hebda, discussed around how enterprise architecture can fuel business agility during a webinar entitled, “Modernizing the Role of Enterprise Architecture in the Age of Digital Disruption.”
How can enterprise architecture help stakeholders invest in new technologies and modernize their IT?
John starts off by saying, “Business agility is a strategic necessity for many, many organizations. You look at the pace of change that our clients are faced with where the average lifespan of a company on the S&P 500 is about 15 years down from over 65. A lot of our clients are forced to move faster, clarify the direction, and many of our organizations spend time on modernizing their IT infrastructure and IT environments to become more competitive and prepare for the future. How can the EA group help their stakeholders pivoting to new technologies, modernizing their IT environments, and adding value in this area?”
On-time and on-budget, but is the project still on-strategy?
Dan says, “One of the things that I think is very interesting and is a ‘great landing, wrong airport’ analogy, is that we’ve seen a number of projects where the timeline was wrong. It starts when someone has a strategic notion from the executive level, and it gets broken down and decomposed and eventually ends up as a series of projects. Those projects end up hyper-focused on deploying, designing, or developing new technology and within that project execution, they successfully deploy on-time and under budget. But did they check to see if what they actually deployed matches the original strategic expectation?” To rectify this, Dan notes, “One of the things we like to do is use capabilities and architecture to establish guidelines or guardrails, and keep the awareness as to what the expected outcome is - not just at the technological level but at the business level as well.”
Instead of saying “No,” enterprise architects should say “Here’s How”
Continuing the conversation, John says, “One thing we see these days, is that folks don’t want to add an Enterprise Architecture overlay on top of an agile program because it may inhibit the overall speed and agility of the Agile teams. What’s been your experience around how Enterprise Architecture can yield more effectively with Agile project teams?”
“I think the more Agility comes into play, the more enterprise architects need to be directly involved in the project instead of being separate,” says Dan. “Architects should be loaned out to participate directly in project executions so that their skin is in the game and they’re part of the team that’s achieving the outcome. In this light, enterprise architecture is not seen as separate and adding some unnecessary burden but rather, EA is seen as someone that can help the Agile teams. So instead of saying ‘no,’ EA says, ‘here’s how,’ and helps the Agile teams to navigate the guardrails, helping them to avoid pitfalls, all the while not slowing the project down and working towards a more likely successful outcome. I think it’s very, very important for the architects to recognize the importance of not being defensive but to recognize that they have to be very cognizant of not slowing the progress down.”
Embedding enterprise architects into Agile teams helps projects go faster
“That raises the interesting question,” says Roland, “Whether you put the architect role on the organizational charts or to be a little bit provocative, do you need enterprise architects embedded in the project and they report to their product owner? That’s an interesting question that obviously needs to somehow be answered.”
John raises another point, “This notion of return on teams where teams become more productive the more they work together. The architects work with the project teams and that becomes more of an efficient process.”
Roland responds, “There is a typical misconception of people thinking that if they go Agile that means they don't have to document stuff. I think that's not true and that was never true.”
John adds to this point, “It’s a dual problem – how do I modernize and how do I move fast. There was a client I worked with that was spending over 70% of their IT budget just keeping the lights on and wanted to free up budgetary dollars to be more innovative. But to get there, we had to shrink and rationalize the technology footprint and decommission applications to free up budgetary dollars and enable the company to pivot. The architecture team was invaluable in helping this organization pivot to a new world of innovation and even identify cool disruptive technologies. All the while this company was modernizing infrastructure and moving faster with more Agile methods. It’s kind of like a twin axle on that one.”
John finishes the point, “So application rationalization is really becoming more a continuous planning process not just a one and done. One really has to continually slice it again because applications become outdated as you modernize.”
For additional insights, please read The Open Group’s “Agile Architecture in the Digital Age,” coauthored by MEGA’s Chief Research and Innovation Officer, Antoine Lonjon