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.
7 Comments
Leave a comment
So true... It is a tight line for EA's to walk. The key is finding the balance, to get the right EA stuff done, making the PM successful, and making sure the business get what they need, while making IT more efficient (Time/$$$/Quality). Glad you're hanging in there...
Being an Enterprise Architect is a role I enjoy but I recognise the scenario.
I think the main underlying issue is that the Enterprise Architect doesn't, in any organisation I have engaged with, actually ever command a budget.
With money comes the power to spend it and influence others who will come to rely on that money being spent in their direction on their project etc.
Without the money weapon, an enterprise architect must rely on their powers of influence and persuasion with the C-level executives, and their governance sign off power at end of project phases and giving approval at project board meetings.
As the enterprise architecture discipline has not yet reached the tipping point where the majority of organisations realise its key importance, this influence and persuasion is still often overruled by JFDI thinking when the going gets tough.
Enterprise Architects do always have to continually demonstrate value and ROI, even if it is indirectly achieved by the delivery projects months away when they implement what you have defined in the EA roadmap.
However I think that Enterprise Architects do need to closely align themselves with the C-level decision makers (CIO, Business management etc.) in an organisation rather than with the project teams to achieve power and influence.
I know this sounds a bit Machiavellian, but if you are aligned too much with delivery then you'll be seen as a [project level] solution architect and not as an [strategic] enterprise architect which is where you want to be in the first place.
It's a fine line to walk.
Before all else, be armed [with a budget].
I think the main underlying issue is that the Enterprise Architect doesn't, in any organisation I have engaged with, actually ever command a budget.
With money comes the power to spend it and influence others who will come to rely on that money being spent in their direction on their project etc.
Without the money weapon, an enterprise architect must rely on their powers of influence and persuasion with the C-level executives, and their governance sign off power at end of project phases and giving approval at project board meetings.
As the enterprise architecture discipline has not yet reached the tipping point where the majority of organisations realise its key importance, this influence and persuasion is still often overruled by JFDI thinking when the going gets tough.
Enterprise Architects do always have to continually demonstrate value and ROI, even if it is indirectly achieved by the delivery projects months away when they implement what you have defined in the EA roadmap.
However I think that Enterprise Architects do need to closely align themselves with the C-level decision makers (CIO, Business management etc.) in an organisation rather than with the project teams to achieve power and influence.
I know this sounds a bit Machiavellian, but if you are aligned too much with delivery then you'll be seen as a [project level] solution architect and not as an [strategic] enterprise architect which is where you want to be in the first place.
It's a fine line to walk.
Before all else, be armed [with a budget].
Great blog post Rik, totally agree with it and recognizable. I think the comment from Adrian about C-level decision makers is essentially about who is sponsoring the EA and if this sponsor has an important say in the projects process. And maybe use the Architectural Contract from TOGAF ;). At least you have something formally...
Hi Rik,
I totally agree with you, there is no alternative to enterprise architecture. Forget about the long lasting ERP implementations from the 90-ties. Customers are changing, ERP solutions are changing, projects are changing. Without a proper re-use of existing components we can never deliver the requested functionality at the required time-to-market.
When the going gets tough in a project with a traditional waterfall approach, lead by a traditional project manager, all the good principles on architecture, standards and quality get lost. So we also need a new project approach in ERP land: Doing things the Agile way. Look at Scrum or Smart and make sure you deliver what the customer really needs. And yes, within this approach the role for an enterprise architect is required from the beginning to the end. The full 100%
I totally agree with you, there is no alternative to enterprise architecture. Forget about the long lasting ERP implementations from the 90-ties. Customers are changing, ERP solutions are changing, projects are changing. Without a proper re-use of existing components we can never deliver the requested functionality at the required time-to-market.
When the going gets tough in a project with a traditional waterfall approach, lead by a traditional project manager, all the good principles on architecture, standards and quality get lost. So we also need a new project approach in ERP land: Doing things the Agile way. Look at Scrum or Smart and make sure you deliver what the customer really needs. And yes, within this approach the role for an enterprise architect is required from the beginning to the end. The full 100%
Now about the re-usability of IT assets across all the projects in the organization, that already exists, and it's within the role of the PMO.
The PMO is responsible of sharing the knowledge across all the projects in the organization, and communicating this knowledge to Project Managers when the need arise.
The PMO is responsible of sharing the knowledge across all the projects in the organization, and communicating this knowledge to Project Managers when the need arise.
This is interesting, and I can empathise with you. I find myself more powerful(?) being involved in high-level Solutions Architecture than being purely in the Enterprise layer. I can influence Business and Technology decisions and have the budget to throw behind these initiatives.
My moto: Architecting the Enterprise: Solution by Solution!
Possibly deserves a whole blog post to expand on it. But I'll let you all ponder on this thought.
My moto: Architecting the Enterprise: Solution by Solution!
Possibly deserves a whole blog post to expand on it. But I'll let you all ponder on this thought.
Well said "Yeah.. being an enterprise architect is hardship these days"
I am not a EA in my current role, but a Solution Architect for a major program at insurance client. Your story mirrors my experience. As a solution Architect i am bridging gap between 30000 feet view of an EA and on the ground delivery teams. However, everyday at work also reminds me of the importance of EAs and Solution Architects in keeping the architecture aligned with long term goal. Sure there are exceptions, but those documented and presented to management, allows to make decisions. Ultimate purpose of having the architects is to design or orchestrate systems in a fashion that reduces the long term RUN cost. I have no doubt that at least for management, architects are vital assets. However, since we have all deliverables that are indirect as oppossed to delivery teams, life gets tough at times, in terms of both acceptability and frustration of seeing the recommendation brushed aside.
I am not a EA in my current role, but a Solution Architect for a major program at insurance client. Your story mirrors my experience. As a solution Architect i am bridging gap between 30000 feet view of an EA and on the ground delivery teams. However, everyday at work also reminds me of the importance of EAs and Solution Architects in keeping the architecture aligned with long term goal. Sure there are exceptions, but those documented and presented to management, allows to make decisions. Ultimate purpose of having the architects is to design or orchestrate systems in a fashion that reduces the long term RUN cost. I have no doubt that at least for management, architects are vital assets. However, since we have all deliverables that are indirect as oppossed to delivery teams, life gets tough at times, in terms of both acceptability and frustration of seeing the recommendation brushed aside.
