Is it better to take a project-centric approach to enterprise architecture (EA) or a program-centric approach?
Sort by:
I totally agree, and I have our enterprise architect as the product owner. But if you have siloed product managers like that — a product manager for CRM, another product manager for ERP, another one for Salesforce — without having an overarching way of bringing things together, you can get people fighting for whichever product they’re passionate about. Then you end up with fragmentation and various things are not coming together properly.
There's another piece to this. We went down that path at a past organization where we assigned product owners, and their roles were similar to that of a business analyst. They would interface between IT and the line of business group that had the most connection with that particular application or function. And if it was shared amongst a number of different groups, it was their responsibility to collaborate and bring those different groups together. <br><br>The issue with that approach was that while it was great to have someone who had responsibility for it, they lacked the understanding of what it meant to build and operate that particular application and function, because these silos still sat behind that person in IT. We tried to integrate those as best we could but it was a complicated organization, and it was hard to tease apart decades of culture. So that's a potential solution, but it exposes the next problem you have. It's like a game of whack-a-mole: You knock one down, and another pops up. How do you solve it?
When we're thinking in that program mindset, we have to consider the bigger picture, including all of the ancillary pieces that connect to it. Even though you're working on this one application or function, when you think about how it fits into that broader context, there’s less of a need for enterprise architecture (EA) to be a discrete function. I'm not saying the need for a discrete function completely goes away but it does start to, and culture is a component.
What replaces the discrete function?
Maybe it is a shared responsibility across the organization as opposed to a discrete function. When I've been in an operational CIO role or an IT leadership role, I’ve observed that the organizations that take a project-centric approach are very constrained and structured. They are the ones that tend to get into trouble, as opposed to those that take a shared program-centric approach.
There is nothing to stop you from having a product owner for your CRM environment, your ERP or your HCM. There is a fundamental difference when you designate a product owner for your CRM landscape. You are expecting that owner to have passion, vision and a desire to engage with their customer to provide the best possible service.
The downside is that when you go down the project route, it's a transactional relationship: You're processing tickets. You're getting inbound requests. And that model is not unique to companies that are building products. There's a tremendous amount of value to overlay in not only the builder but also the buyer. When you talk about a product like MuleSoft, I would have a product owner for that because that person needs to have incredible passion and understand that they have a humongous role to play in the way that integrations occur — they have the ability to make or break incredible value add through that.