/Tag: Project and Program Management

The Architecture Manager – the Forgotten Enterprise Architecture Role

By |2014-11-11T16:46:03+00:00November 11th, 2014|Enterprise Architecture|

I’ve met many Architecture Managers over the years.  Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant.  The men and women called to serve in this unique role have a distinct, and uniquely important role to play in the success of the Enterprise Architecture function in their enterprise.  Yet precious little is said about them.

In this article, I’ll touch one some of the key qualities I would expect to find in a successful Architecture Manager.

What value does an Architecture Manager provide

As the role of Enterprise Architect matures in organizations around the world, we’ve begun to see the tremendous impact that an effective architecture manager provides.  In many ways, the Architecture Manager is the single most important role in the department, but also the most difficult role to fill.  That is because, typically, the role is filled by a person who “moves up” from being an Enterprise Architect.  Unfortunately, being an excellent EA is poor preparation for this particular role.

An Architecture manager is:

  • An expert at “selling upwards” – Convincing management of the need, role, measures, and successes of the EA function as a whole.
     
  • An expert as “peer selling” – Convincing enterprise peers of the value of requiring their staff to collaborate with an architect, especially when doing so forces a change on the processes they would otherwise use.   (this is one of the most difficult and valuable activities an Architecture Manager can do).
     
  • A visionary for the development of the function – Convincing the team, the management, and internal partners of the vision and desired impact of Enterprise Architecture in the organization, keeping in mind both short term and long term goals.   Without vision, the function cannot grow. 
     
  • A good people and resource manager – Capable of aligning people to roles that can be successfully performed, helping his or her staff to grow to meet their potential, and finding new resources from within and without the enterprise capable of performing an architecture function.   It’s amazing how many architects move up to a manager role and have no idea how to do this well.  This blind spot can kill a team within a year.

 

In my travels, I’ve met both good Architecture Managers and not-so-good Architecture Managers.  The ones in need of improvement nearly always struggled at one of the above.

What are the responsibilities of an Architecture Manager

Enterprise Architects are rare birds… especially good ones.  There are many folks who have worked to become Enterprise Architects, and a few who succeeded in recognizing the uniquely holistic role of an EA.  Typically an EA has to manage through influence alone, because it’s rare that an EA has a team of resources assigned to him or her.  But an Architecture Manager is in a different position.  They do have a team, and unlike other efforts where they could be objective about a business leader’s business processes and functional alignment, they now have to perform architecture on themselves.  Sometimes, they succeed.

If you find you need to hire an architecture manager, you’ll need a list of responsibilities for your hiring team.  Just copy the following list.

The responsibilities of an Architecture Manager include:

  • To set the vision, goals, and measures of success for the Enterprise Architecture function within an enterprise, recognizing the current team maturity, skills of the team members, and readiness of the enterprise to accept the role as desired.
  • To measure the value of the efforts of the Enterprise Architecture function in a neutral manner and present those measures at appropriate times to stakeholders within the enterprise to earn buy in for the function and the funding it requires.
  • To create, refine, and oversee execution of the internal processes of the Enterprise Architecture function, including documenting processes, building support for points of interaction, and ensuring the deliverables match the expectations and timing needed by internal partners and stakeholders.
  • To manage the team members of the Enterprise Architecture function effectively and within the required parameters set by Human Resources.  This includes hiring staff, setting team goals, and conducting performance reviews.
  • To manage the assignment of resources to necessary priorities within the enterprise to meet conflicting strategic needs, and shielding the team members from being pulled out of role.
  • To act as an evangelist for the role of Enterprise Architect within the enterprise, working to build support for the function and its staff members among internal partners.

 

What should an Architecture Manager know

Some of this is pretty obvious, but it’s worth stating anyway.  The architecture manager has to be familiar with enterprise architecture.  But they also have to be familiar with how things can work in an organization, especially if the focus of the EA program is related to IT (as it nearly always is).

  • Experience with and understanding of the deliverables and value proposition of Enterprise Architecture.
  • Deep understanding of the methods and processes an appropriate EA framework. 
    • For telecom, this would be Frameworx (formerly NGOSS and eTOM).
    • For US federal government, that would be the FEA or DODAF.  (in different countries, there are different governmental frameworks). 
    • For private business, the leading frameworks would be TOGAF in first, with a tiny number of organizations still using Zachman. 
    • A small but growing number of companies use the Pragmatic EA Framework (PEAF). 
    • Most organizations roll their own, often from TOGAF, so starting there is the safest.  Note that a certification in TOGAF or the Zachman Framework is a great start.
  • Strong written and oral communication skills
  • Strong and demonstrable systems thinking and strategic thinking skills.  The ability to capture the key elements of a system into a simple abstraction that empowers good decisions.
  • Solid business financial skills.  Demonstrable ability to perform cost benefit analysis and manage the budget of a team.
  • Strong business negotiation skills, influence, conflict resolution, and political savvy
  • Demonstrable leadership in Portfolio Management, Project Management and Enterprise Change Management
  • Multiple years of Strategic Planning experience, preferably in a governance role

 

What should an Architecture Manager NOT do

In many cases, people who move into the role of Architecture Manager worked their way to that role as an architect.  They may have been a technical architect, solution architect, business architect, or enterprise architect.  In many organizations, these roles are deeply technical.  Of all the architecture managers I’ve met, the overwhelming majority are technologists.

Unfortunately, most technologists don’t have the skills to focus on the responsibilities listed above.  It is tempting to continue to be a technologist once moving to this role.  It is also suicide.  Your term as the “Vice President of Strategy and Architecture” will be short if you cannot step back and let your team perform the technologies or modeling activities typical of an architect.  This means, for the architecture manager himself or
herself: No modeling,  No coding,  No time spent geeking out.  (Ok, exception, fiddling on the side is fine, especially if you want to “stay warm” with your technical skills… but nothing deliverable.)

Where should I look to find a good Architecture Manager

First place is the same as you’d expect for any role: find a person who was successful as an Architecture Manager in another enterprise.  Be careful of people who performed  but did not succeed as an Architecture Manager.  Most folks fail.  Find out if the function continued after they left, and if their team enjoyed working for them, and if their stakeholders saw fit to provide an increased level of interaction with their staff members.  Look at examples of their teams’ deliverables and ask about their ability to build and maintain new business processes.

Second option is to bring in an experienced architect and let them take on the role.  Assuming the team already exists and is well accepted within the organization, this is a reasonable approach.  Finding a seasoned architecture manager is extraordinarily difficult, so this may be the only rational option.  The person you select should have worked for at least six years as an Enterprise level architect, with increasing levels of responsibility, and should preferably have been a resource manager at some other point in their career.  If the program does not already exist, see the next section.

Third option is a seasoned manager who has no experience as an Enterprise Architect.  This may be a distinguished technical architect, or the leader of a highly visible program in the past.  These folks are expected to bring expert team leadership skills and deep technical skills.  The biggest challenge that they will face is being able to adequately learn the role.  Unlike most other management roles, the Architecture Manager must be able to SELL the value of the role of Enterprise Architect, and that is extraordinarily difficult to do if the manager wasn’t an architect first.  The learning curve is very steep.  To pull this off, the Architecture Manager will need a good mentor or an experienced consultant to help guide them through the first year in role. 

Building a program around an Architecture Manager

If you don’t already have a functioning Enterprise Architecture program, your very first hire will be the Architecture manager.  This role will be doing a great deal of heavy lifting in that first year.  Setting up processes and deliverables.  Making sure that the stakeholders buy in to collaborating with those processes.  Hiring and situating staff.  Creating priorities and managing resources.  Setting up measurement and demonstrating value.  It’s a tough road to build from scratch while providing value.

The only advice I can give: do NOT build a new EA program around an Enterprise Architect who has never been an Architecture Manager before.  That is simply too much for a single person to handle.  Going from EA to Architecture Manager of a new program is a huge leap, and I have never seen it be a successful approach in the long term.  The person you hire may be a “survivor” who knows how to avoid being fired, but that won’t make them effective.  Once they move to another role in the enterprise, the function will likely vanish.

You need the Architecture Manager to be effective.  To build a program with lasting value.  To build a program that matures over time. 

So if you are building a new EA program, build it around an experienced Architecture Manager.  Then support them with resources that they did not ask for: (a) an outside expert who can provide a neutral point of view and sounding board as they build and struggle that first year, and (b) Serious “air cover” so that they have the time needed to build the team, create the processes, build support, and demonstrate early value.

Conclusion

The single most important person in the Enterprise Architecture function is the Architecture Manager.  This critical role is part visionary, part marketer, part people manager, and part evangelist.  They have to change the organization and keep the change from undoing itself.  The role of Enterprise Architecture is highly dependent upon the skills and the focus of this key role.  Choose wisely.

Are we documenting the wrong things?

By |2010-11-20T12:57:47+00:00November 20th, 2010|Enterprise Architecture|

James McGovern blogged recently about his dislike of documentation as part of software development.  While I disagree with his style and penchant for hyperbole, McGovern asks some good questions.  Do we create documentation “because we should” or do we create documentation in situations where it has proven useful, where people read the documentation, and where actions are taken based on that documentation?

McGovern concludes his post with the following question:

“I am of the belief that documentation should explain decisions taken and not taken, Why an approach, architecture or algorithm was selected and what else was considered and rejected. Bet the developer in most shops wouldn’t have documented this since he/she may not even have visibility into the choices made along the way. So, when you are asking for documentation, what are you really asking for[?]”

I agree with both his statement of value (Documentation should explain decisions) and his concern about having developers do the work (he/she may not even have visibility).

But let’s take that one step further.  If documentation is valuable in that situation, and if developers can’t meet that need… then who can?

In my experience, the architect is one key person who has visibility to the choices made along the way.  She may be a system architect (for technical decisions), a business architect (for localized business decisions), or an enterprise architect (for cross-organizational business and technical decisions).  When properly supported, an architect is one of the few people charged with documenting alternative designs, getting discussion and consensus, and building a solution that everyone can buy in to. 

But what would that documentation look like? 

This architectural document is NOT a design spec.  It is NOT a requirements document.  It is NOT an API. 

Useful documentation from an architect needs to focus on decisions.  From those decisions, come rules

In my current practice, I have developed a new document type called a Technical Policy and Advice Document or TPAD.  This document is focused on a single key technical decision (with all motivations, scope, exceptions, and signatories).  These are “technical policies” in the sense that they are decisions made and ratified across a group of people.  The second half of the document is “advice” which describes a design useful for implementing the technical policy.  The design is documented using architectural models and the allocation of responsibilities.  The document is short (less than 10 pages) and specific.  The document includes both a business decision and a technical approach for executing it. 

I’ve had a lot of “push back” against bringing together these two elements in a single document.   There is a downside in that signatories can’t agree to “part” of the document.  Different people have to agree to both parts.  Putting them together in a single document make for a more difficult decision-making process.   On the other hand, Microsoft is a company where the opinion of a technologist is taken very seriously.  Business decisions are influenced by technologists, and if you go to one and not the other, decisions are simply not made.

For documentation to be useful, it has to be used.  This documentation is useful because projects can be based on it, and technologists throughout the company can see the high-level business people who have made a decision.  If they don’t like the decision, they can speak to those business leaders.  This visibility helps prevent passive-aggressive business behavior. 

Project managers and Developers can read that documentation and take actions based on it.  It is architectural at the business level as well as the technical level.  And, hopefully, McGovern will like this aspect: developers don’t write it. 

When demand management is confused with alignment…

By |2010-08-12T17:49:32+00:00August 12th, 2010|Enterprise Architecture|

One of the most common, and reasonable, mechanisms for achieving clarity on the roadmap for a single platform is “demand management.”  It is also one of the areas of IT that is both rapidly evolving and poorly defined.  I’d like to offer an opinion about what demand management is, and is not, and how it meets some, but not all, of the planning and governance needs of IT.

Caveat Emptor: In the post below, I’m sharing my opinion, which will probably differ from yours.  I ask that you follow along with an open mind, and consider the possibility that we may be using the same words in different ways, before pointing out how “wrong” my thinking is.  That said, I would love to hear feedback from others, and to improve my own thinking in this space.  Please share your thoughts.

Assertion 1: IT Demand Management is poorly defined.

In the book “IT Success: Towards a New Model for Information Technology” author Michael Gentile provides a reasonable description of demand management… or at least he starts to.

Using the fundamental premise that not all demand from the business will be approved—because of business priorities on the one hand, and IT resource and scheduling constraints on the other—the best way of representing demand would be via a funnel. Demand from the business enters at the top, follows one or more decision-making processes, and then either exits at the bottom as approved work to be executed, or remains in the pipeline pending further evaluation. – Michael Gentile, “IT Success: Towards a New Model for Information Technology” as excerpted in CIO magazine (link)

This is a reasonable explanation of what demand management is.  As a more formal definition, IT Demand Management is the practice of collecting together all of the demands that will be fulfilled by a particular IT group, team, or organization, and balancing all of those demands with the limited supply of resources in order to produce an ordered list of activities, on a specific timeline, for that group, team, or organization to fulfill. 

Assertion 2: Demand management does not deliver alignment

Unfortunately, if the article in CIO that I cite above is any reflection on Mr. Gentile’s book, he goes wildly off the rails, describing demand management as the process by which IT achieves alignment and delivers value.  That is an interesting notion but it is fairly easy to disprove. 

What proof do I offer?  A counter-example.  Microsoft IT has been performing the kind of demand management that Mr. Gentile describes for well over a decade.  At no time did demand management deliver alignment.  When alignment was achieved, it was achieved in spite of, or regardless of, the maturity of the demand management process, and not because of it.

Alignment happens when a team or group of people decides to build the right solution, instead of building the solution right.  But more importantly, alignment occurs when a team decides NOT to build something, or to build something less than was requested, or in a different order than requested, because it meant that the business was more able to deliver on strategic goals. 

Mr. Gentile and I agree on this understanding of alignment.  We disagree that demand management gets you there.

Assertion 3: Alignment processes occur BEFORE demand management processes

Starting with demand is important and useful… if you already have a solution, and that solution has demand.  Once you have a solution, you have to manage the demand against that solution.  You don’t have infinite resources.  So if there are four teams within your company that want to use your public website to meet their goals (let’s say lead generation, ecommerce, customer support, and investor relations) but only one team that can manage the public website, then you will need to use demand management.  You need to collect the requirements from different teams, go through a rational and mature process for prioritizing those requirements, create a roadmap showing which requirements to meet in which order, communicate that roadmap, and track to it.  That is demand management.

However, if you THINK you need a solution to a problem, and you are a business leader, your request could go into a demand management “funnel” and come out the other end producing a solution to a problem that you did not have.  That is misalignment, and demand management will do little or nothing to prevent it.

Alignment requires a different process, one that examines the goals of the business, rationalizes them, finds common impact areas, and FRAMES THE DEMAND.  Alignment decides what demand is rational.  Alignment occurs BEFORE the demand management process does.  To accept all demand against IT without performing alignment activities first is an anti-pattern.  Demand management practices lend an air of “officialness” to the resulting roadmap, and once that roadmap is produced, it is very difficult to come back to the project teams and point out that the hard-won priorities don’t align to business strategy!

Discussion and Conclusion

These are tough assertions for many IT folks.  This is one of the major reasons, in my opinion, that Enterprise Architecture is often unwelcome within IT, but well received outside of IT… because Enterprise Architecture attempts to achieve alignment in spite of the often well established practices of IT demand management.  Without clear understanding of the dependency that demand management SHOULD take on alignment, the processes will conflict.  Demand management will produce a list of things to do, and alignment will produce a different list.  The only way to reconcile this is to perform alignment activities first, and then demand management activities, to produce the ultimate roadmaps.

That is my perception, anyway.  I know that some folks will assert that demand management is a larger process, and it includes the “alignment” activities that I speak of.  That may be an interesting matter of semantics.  However, if this were true, then the “funnel” metaphor breaks down, because any demand management process that includes alignment activities would not resemble a funnel.  In a funnel, all of the stuff goes in the top and the stuff coming out of the bottom is a direct reflection of what went in the top.  Alignment assumes that most of the stuff going in the top is wrong, and that a lot of stuff is missing. 

The “funnel” metaphor for demand management is accurate, as long as demand management doesn’t deliver alignment… and it doesn’t.

Your thoughts?