Enterprise Architecture

If you haven't already done so, take a 'gut check' of where you stand personally and professionally with the following people in your organization (given in no particular order):

• The CIO
• The CTO
• Your peer group of architects and senior IT management/technologists
• The project managers and PMO if you have one
• The development team leads and senior developers
• The business unit heads and sponsors you routinely deal with
• Members of non-IT business units you routinely deal professionally with

Why am I asking this? Well, as an enterprise architect, you're in a challenging spot because all of the above constituencies play a big role in you doing your job well. That is a lot of people to keep happy, but their overall satisfaction with you and your work is important because the loss or withholding of their support can put large roadblocks in the path of what you're trying to accomplish.

There are 2 direct ways to look at your business relationship with these stakeholders: what you get from them, and what you give to them. Here's an example of this with some of the constituancies listed above:

CIO - gives: Funding, Formal Approval, Strategic Direction; gets: Architecture

CTO - gives: Technology Strategic Direction/Standards,Thought Leadership; gets: Technical and Stategy Input/Advice

Project Managers - gives: Project-based Strategy, Leadership, Tracking/Status; gets: Buildable Architecture, Subject Matter Expertise

Development Team Leads - gives: Technical Leadership, Development Strategies, Development; gets: Functional Architecture Specifications, Interface/Data Specifications, Exchange Between Architecuture and Development Standards & Issues.

Business Sponsors/Unit Executives - gives: Funding, Approval, Requirements, Process Direction; gets: Working Software, Understandable Mapping of Technology Environment to Business Requirements and Processes

A couple of things to note before I continue - these are examples of stakeholder give & get relationships and if you attempt this exercise, the players roles and titles will most likely be different in name or function. And, I really wanted to put this in a table to make it clearer, but I didn't want to imbed a Word file in this post...if anybody has a good way to do this without a file and without changing blog sites, I'm all ears and grateful...just leave a comment to this post or e-mail me with my thanks in advance.

OK, back to our program. This exercise can also be enhanced by adding other data or intuitions such as 'perception of the IT organization,' 'perception of the EA function,' and others that are relevant and some kind of estimate low-to-high for each. Once you have completed this, then you can determine where to focus your energies with respect to building and maintaining/improving relationships and trust with the business and IT leadership and development.

I recommend doing a simple review like this at least once per year, and more often if there are signifcant areas for improvement. If you have, or can achieve, a relationship level with the stakeholders in which you are (or become) the trusted advisor or steward, it's going to make a number of aspects of your job as enterprise architect easier, and you can better achieve consensus or coalition-building to support initiatives you seek to develop and execute.

While this scheme may seem a bit simplistic, that's by design. You want simple truths like this so you can take appropriate action without much hand-wringing (and time-wasting) over what to measure, how to do it, and how often. We have more than enough complexity to deal with as it is, and getting a read on where we stand with stakeholders in a manner such as this provides quick benefits to the business, the IT organization, and ourselves.

Finally, this is not to be construed as a performance review, its more how the EA function (and by extension, you and your peer architects) are viewed by various stakeholders in the organization.


enterprise architecture