In most large IT organizations, there are many projects in-flight at any moment in time, at various stages of maturity. Without a consistent technical perspective across these projects, things can go haywire, with enterprises forced to support too many disconnected interests and technologies. This can lead to some interesting conversations for external partners trying to figure out the company’s IT landscape:
Q: “What kind of tool do you use for X?
A: “All of them.”
Many CIOs respond to this problem with a separate team of enterprise architects who are responsible for defining, maintaining and enforcing technology standards across the company. The idea is that this group will help keep internal staff, consultants and contractors aligned on the IT ecosystem and how it will evolve in the future.
At the same time there will be architects/team leads/coders who will be assigned full-time to actually deliver the projects (and in turn, the value) that the business is funding. Many times these people will feel constrained by limitations placed on them by the enterprise architect group, whether it’s the use of a particular process, standard or technology stack. By keeping architects segregated, the project itself will bear the burden and the costs of decisions made outside the delivery team, or in other words, by chickens not pigs. This goes against widely-accepted Agile best practices and can be a recipe for frustration and project risk.
One approach for resolving this conflict is to assign enterprise architects on a rotating basis to delivery projects within the organization. This does not necessarily mean that they should be writing code themselves (for what it’s worth, many in the Agile world would insist on this part), but should be held accountable for both the specific designs and issue resolution that are key to project success. In other words, seeing what life is like as a ‘pig’ will give them a whole new perspective on when to apply the rules and when to break them.
Many insurance organizations are looking not just for a legacy replacement of their expensive and outdated mainframe systems, but also for a true business transformation to meet the needs of their own stakeholders. Mixing the broad view of the typical enterprise architect with the close-to-metal challenges of large-scale transformation is a recipe for better long-term business and IT value.