Every organization has one. For some, it can lead directly to a path of enlightenment. Others may use its rigid structure to create an impenetrable fortress of strength. For the unfortunate, it becomes an inescapable labyrinth of hopelessness. Yes, it’s the org chart.
Okay, let’s be fair, it’s actually not the chart that’s the real challenge, it’s the organizational structure. Any organizational structure creates boundaries, and those boundaries create opportunity for divergence, whether in strategy, opinions, processes, or just about anything else. The challenge is figuring out how to structure the organization to diverge where you need divergence, but to be consistent where you want consistency. It’s no surprise that organizational structure is considered by some to be part of the enterprise architecture. Just as we try to organize our technology portfolio in the best manner to achieve the desired business goals, we need to organize our human resources as well. More importantly, just as management may choose to reorganize its human resources as the business goals and operating context changes, the way we organize our technology portfolio needs to change as well.
The organizational structure poses a particular challenge for the practice of architecture, particularly when it comes to solution architecture. I’ve seen at least three different models for organizing the architecture practice. First, is the centralized model where all architects report up to a single Chief Architect or Director of Architecture. There may be some middle management in there, but there is always a solid line leading to the top. As you might guess, this usually leads to a high degree of consistency, but can have challenges in scaling to meet demand, retaining business domain knowledge, and of course, ensuring that the centralized resources actually get used by projects and avoiding “rogue architecture.” The overuse of the term “architect” in job titles these days makes this even more problematic, as senior or lead developers may now have the title of Java/.NET Architect. It may also create delays in decision making, because the solution delivery has one reporting structure, while the solution architecture has a different reporting structure. If there is a disagreement, these two management structures must come together to resolve the difference, or it must be escalated up the chain.
A second model is a separation of the Enterprise Architecture function from the Solution Architecture function. Enterprise Architects have a solid line to the Chief Architect/Director of Architecture, Solution Architects report through a different structure, perhaps having a dotted line back into the EA organization in a matrixed structure. Consistency becomes more of a challenge, because Solution Architects will likely receive more direction from their management structure than from the EA team. It also creates challenges for the EA function, because now the EA team is at risk of being completely disconnected from solution delivery. Even in the centralized model, the bulk of the input into the solution comes from the solution management side of things. Now, that push will be even stronger, with architectural management struggling to maintain a voice. That voice is sometimes mandated through an architectural review board, but if that’s the only time that architectural management has the solution architect’s ear, the effort is likely to struggle with EA being seen as an ivory tower, rather than a necessary contributor to solution success. I’ve seen this model more than either of the others, however.
The third model would be the completely decentralized model. In this case, there is still a practice of architecture in the organization, but it is completely distributed. Solution architects, and perhaps domain architects, are scattered throughout the organization. A virtual team may exist, and there may even be a Chief Architect/Director of Architecture, but the role may largely be one of information sharing and coordination, and not really about architecture management. What’s good is that there’s not much risk of being perceived as an ivory tower, but there is significant risk of poor architectural alignment. If the boundaries of diversification are based upon an assumption that business units do not share customers, what happens if the situation changes and they do? Even ignoring the potential for this situation, decisions on centralization versus a matrixed approach are likely made locally within each business unit.
So what model is right? First, a completely decentralized approach is really only suitable for companies with a completely diversified operating model (see this book if you don’t know what that means). So, it really comes down to centralized versus matrixed, and that will either be applied at the business unit level for a diversified company, or at the enterprise level for other operating models. Both centralized and matrixed can work, but there is a catch. I’ve used the term “architecture management” in this blog. As I wrote this, I kept thinking about parallels to project management and a PMO. I’ve seen centralized PMOs where all project managers report into a single organizational group, and I’ve seen decentralized PMOs where individual project managers report into lines of business while a core group of resources that look at things from a portfolio perspective report into a Director of Product Management. The catch is consistency. If each project manager did things their own way, it is going to be extremely difficult for anyone to manage things at a portfolio level. Without establishing some minimum level of consistency that produces the necessary metrics and information at the right times for portfolio level management to happen, you’re sunk. Fortunately, for project management, the need for this is a well accepted practice. No one wants to wait to find out that a project is $100M over budget until after it happens. If you have that consistency, you can make either model work.
In the case of architecture management, things are still maturing. The problem is that we are at risk of focusing solely on consistency, without properly understanding the outcome that consistency is supposed to create. While finding out that you’re $100M over budget after it’s been spent is well understood as a bad thing, is finding out that someone has built a component that already existed elsewhere in the company a bad thing? Not necessarily. Those decisions need to be made in the context of both the project’s goals and the enterprise’s goals to make that distinction. Pursuing enterprise consistency when there are only project goals involved in decision making puts you at risk of being perceived as an ivory tower. At the same time, it may be necessary to pursue some base level of consistency prior to establishing that enterprise context, otherwise the context may be perceived as irrelevant. This can happen when the practice of solution architecture really isn’t being practiced at all.
My final advice is this: a centralized path will definitely lead to the most consistency, but you have to be rock solid in your justification of the need for an enterprise viewpoint, because that centralized model creates management overhead, risk of resource availability, and the potential for conflicting direction. A decentralized model is at less risk of having resource availability issues, but makes consistency more difficult and is more prone to sacrificing enterprise direction for project delivery. Ultimately, it will come down to whether your organization has been successful with matrix management approaches or not. If it has, you should be able to make a decentralized approach work. If you’ve never been successful with matrix management, then a centralized approach will likely be necessary. Finally, if you go with a decentralized approach, but have very inconsistent architecture practices, I strongly recommend that you establish an architecture mentoring/facilitator practice. In this, members of the centralized EA team facilitate one or two day architectural workshops. This can ensure that things are done in a consistent manner, the voice of the enterprise is brought into the solution architecture process, but the risks associated with a completely centralized model are mitigated.