Just returned from another assignment as an enterprise architect. In the UK this time. Nice job, great people, well-received deliverables. But again, it was not easy for me and the team to finish 100% of our original statement of work. And to play a prominent role also in the last part of our enterprise architecture cycle: the governance of the implementation projects.
Why can life be so difficult for enterprise architects these days? Why is it often so hard for enterprise architects to stay in the driving seat until the end of the (enterprise architecture) program? Two reasons:
1) In most organizations, project delivery still rules. Sure, C-level management allows enterprise architects to develop their holistic views of the business and IT and to govern the organization’s projects that implement all these great views. Because C-level management wants to be ‘in control’ of things and enterprise architecture seems to be the right way to establish this. At least, beforehand. Reality shows however that – as soon as the going gets tough on projects and projects are running out of budget and time – project delivery takes over control slowly but steadily. Projects are allowed to take all sorts of shortcuts and neglect any principle and guideline so carefully predefined by enterprise architecture. Leaving the enterprise architects behind as a voice crying in the wilderness.
2) On the other hand, project people often complain about the quality of the enterprise architects’ deliverables. Enterprise architects are accused of producing too much paperwork, tending to stick to fluffy and too generic business and IT principles, high level business processes and often completely skip the step to where it really gets interesting for most projects: the information systems and technology part of enterprise architecture.
Yeah.. being an enterprise architect is hardship these days. Sometimes I consider going back to where I came from: back to project delivery (‘projects, bíííg projects’), back to the ERP rollouts that we were use to in the 90-ties, exiting cutover weekends with pizza’s, no sleep but only each other working on real stuff. Back to the time where we didn’t run the risk to be sent home after 80% of our statement of work but only when the (implementation) job was done.
Those were the days.. however… there is one thing that keeps me going in my current profession: my strong believe that there is no alternative to enterprise architecture.
Projects are managed by projects managers. And good project managers do what they are paid for: reach a predefined target, within time and within budget. It’s good that we have them. And they should stay. But today we are not only interested in a bunch of stovepiped project deliverables anymore. We want re-use of IT assets across projects and we are more than ever interested in project deliverables that are interoperable across the enterprise and beyond and play a role in a broader context. Yes, we still love our project managers that focus on a particular scope and protect that particular scope. But in this era of cloud computing, interoperability, re-use and agility we also need a strong, corporate body that safeguards that the projects are not only doing what is good for the projects themselves but also (or more importantly) do what is good for the enterprise as a whole.
And that’s why I want to stay in enterprise architecture. I even got my TOGAF 9 certification, this week. Good, hey? I learned about the Open Group’s ‘Boundaryless Information Flow’ and the re-use of architecture building blocks and solution building blocks across the enterprise. Great stuff!
So, my enterprise architecture dream is still alive. And with my certificate on the wall I have the theory in the pocket. Two things that need my continuous attention: 1) convince my C-level management to keep me and my colleagues on board until 100% of the program work is done (which includes the governance of implementation projects!) and 2) convince my C-level management to resist the temptation of approving short term and shortcut decisions enforced by project dynamics.
How to convince them? By doing an even better job than I do today. By delivering better enterprise architecture deliverables. Deliverables that are concrete, address both business ànd IT and their alignment. Deliverables that serve corporate goals and objectives but also help projects on an implementation level. And by showing an attitude that finds the right balance between high-level, time-consuming strategy thinking and the dynamics of projects that are in their no-nonsense, ‘going-gets-tough’ phase. That’s the key to succesful enterprise architecture.