Technical Mastery is not a goal for an Enterprise Architect…

An enterprise architect is a true hybrid. You must be able to help business people of all disciplines work in problem spaces that cover the external eco-system, business models, operating models, processes, organisation, technology and information. The down side is that you almost certainly will not be an expert in any one area. 

You will be a jack of all trades, master of none. This leaves you open to accusations, particularly from IT architects, of being a lightweight, of lacking depth, of being technically weak and out of date. This can be painful for an enterprise architect with a background and reputation as a technology guru.

Business people tend to be kinder.  They appreciate someone who has come over to their side.  They need IT people who understand and view their problems as business issues.  They want an honest broker. But you are not one of them and you will be in deep trouble if you start to think that you are, but you are trying. 

Being a hybrid that has moved from IT, being a true enterprise architect, puts you in the middle. You are no longer in IT, but you can’t transition to the business.  You can add huge value by bridging the gap, you can also get lonely because you just don’t fit.

To remain valuable, you must be learning all the time. When a new technology arrives, you need to understand the key features. What business value can it add? What is just hype? Can you anticipate the gotchas? How does it supersede old solutions and address issues in older technologies?  What is the new language that goes with it, how does this relate to the old language?

Growing business capability is equally important.  This happens at several levels – what are industry trends, what is the latest thinking for improving business operations, who are the new entrants in the market, where are the threats, where are the opportunities, what is happening on the shop floor, how is technology changing the business?

You won’t have time to be an expert technologist but you will be able to engage in strategic decision making and set a technical direction that delivers business goals – and that is where an IT oriented enterprise architect can add value, not by indulging in technical mastery.

Get out there!

Enterprise architects are often accused of “living in ivory towers”. They complain that their work is ignored. Architecture teams have their numbers cut, they are abolished, their staff are scattered around the IT function to “where their skills can be applied usefully”, and architects can be seen as an expensive luxury that adds little value. A good concept that fails to deliver!

A good enterprise architect invariably has significant practical experience at the sharp end of systems development, service delivery, or in the business. Good architects maintain contact with their roots and they develop new ones. This is critical to the execution of architecture work – and we must always remember “architecture is pointless without impact”.

An enterprise architect must have a range of practical skills covering data, applications, infrastructure and the business that they deliver to. The key here is practical. An architect achieves delivery through others. Those others must understand and respect the architectural insight. This means that architects must have credibility when they advise on decisions and implementation.

The foundations for achieving this are experience, sound understanding of the principles, up to date knowledge, well worked through advice and good communication skills.

However, there are other key activities that we have to work at continually:

  • Get out there in the business – I am out at the sharp end of the business at least once a month and I encourage my team to do the same. We need to see the reality of the people who make the money or deliver the service. We need to talk to them and understand their day to day problems. We need to understand the opportunities for improving performance where it counts. We need to observe the impact that our architect work has on real people. We need to see how we have succeeded or failed. Our conversations with business managers and in IT will then have more credibility.
  • Get out there in IT – What is good for the business is good for IT. But here the opportunities to get involved and help are much greater. As architects, we have information, skills, knowledge and tools that can help in development and service delivery. We can take complex problems away and let development and service delivery team focus on their core tasks. If we offer to take a problem away then we must deliver, we must deliver on time, we must deliver a solution that is easy to take on. If we fail then we lose credibility. If succeed then we have people willing to follow our guidance. We also have advocates.
  • Get out there amongst the managers – I want my architects talking to the Head of Internal Audit about business continuity. I want my architects talking to board directors about new operating models. I want my architects talking to the Strategy Director about new lines of business. I could take the credit; I could be in the meetings. But it is my team that deliver; it is my team that need the day to day relationships to be more effective. My team has a lot more bandwidth and capability than I have. My role is to facilitate their involvement, build their business and interpersonal skills, back them strongly when the going gets tough, help them to understand the politics, make sure that the whole team is coordinated, and to support and mentor them so they are effective.
  • Follow through to delivery – Don’t walk away when the concept, the options or the high level design has been communicated. If you do it will be misunderstood, corrupted, its integrity will be violated, or it will be discarded. However well you communicate, no one understands your ideas better than you do, and no one is more committed than you are. When you walk away and your advice falls apart, it is not because it was bad advice. It is usually because it lacked interpretation in the light of reality; it lacked a nuance that you could not have foretold. You needed to be there to make a small adjustment. You needed to be there to say “not in this situation”. You needed to be there to make sure that the job was completed properly. When your advice has been delivered to the business and is achieving benefits then you can move on.
  • Be available – You can schedule yourself into meetings, and take a formal part in projects to get you out there. But you also need to be available when other people want you. There needs to be slack in the schedules to allow informal contact, there needs to be a service culture amongst the architects. We don’t mind if you drop by any time, we are not too busy to build relationships. We have 30 minute “surgeries” every morning for anyone who wants to turn up and talk.
  • Be flexible – In order to get out there, we need to be flexible. Architects needs to cover for each other, architects need to shuffle the workload amongst themselves as a natural way of working. It is critical for me that the team is a self managing team. I set priorities, the team organise the workload to meet the needs without heavy planning.
  • No silos – I got rid of job titles such as “project architect”, “data architect”, “infrastructure architect”, we only have enterprise architects. Everyone has a focus and I try to align this with aptitudes, interests and capabilities. But I expect everyone in my team to be credible cover for everyone else, my role is to grow the skills to accomplish this.

It’s not about numbers

Some years ago I was appointed as an interim manager to be Head of Architecture for a FTSE 100 company. The scope of my role was applications and infrastructure – business and data architecture was under another manager.

I had a team of 16 architects who had over the last nine months produced numerous architectural artifacts. They were very clever documents explaining all the options that had been evaluated, the evaluation process, the decisions made, and the reasons for each decision.

The team had lost its direction; it had done a lot of abstract architecting but nothing (zero, ziltch, nada, nix, diddly, zip) had been delivered. There was no plan to achieve delivery. Now was the time to get active and use this stuff to shape the IT service delivered to the business. We needed to get the application and infrastructure implementation teams to deliver the architectural vision that had been so painstakingly developed.

How did we get there?

  1. Get the right people
  2. Understand your customer
  3. Get a process
  4. Get some architectural artifacts to support the process

The Right People
I wanted architects who had the following traits:

  • Understanding of the business
  • Rapport with managers, users, developers and infrastructure staff
  • Verbal and written communications skills
  • Technical knowledge
  • Pragmatism
  • Bravery
  • Ability to operate with minimal supervision

I interviewed the team and I moved 12 out of 16 out of the team. Yes, that’s right I was left with 4 team members. I now had a strong core team capable of being a high performance self managing team.

Who is the customer?
As enterprise architects we have a complex customer base. Our aim, like all people working for the organization, is to help achieve the aims of the board of directors. An effective architecture team is visible at this level and has to be mindful of the impressions created at this level. For example, expensive resource that cause delay to business change will not last very long.

The business middle management implement change, applications are just a part of the change they are delivering. Sometimes they are parochial, narrowly focused, and often highly political. They have the ear of the directors and can make or break architecture and architects. You have to play the long game, sometimes compromising on minor details to ensure that the major gains from architecture are not lost.

The users experience the results of architecture. They have the ear of their management, they too can make or break architecture. It is absolutely essential that solutions are usable when they get into the hands of users. You cannot blame the developers for poor implementation, you cannot blame managers for cutting the budget. If the solution doesn’t deliver for the users then the architect is to blame.

Architects don’t implement, other IT staff or contractors or consultants or outsource partners do that. They consume architecture and deliver applications and infrastructure solutions that should meet the needs of the business. Get architecture right and delivery is quicker, cheaper and higher quality.

Get a process
The keys to the process are:

  • Put the most effort where there is the most risk to the business – you need a triage procedure.
  • Get in at the beginning (or before that if you can) of a project
  • Understand project requirements
  • Ensure that the project is aligned to business goals (if you don’t do this then you are not an enterprise architect)
  • Guide the design so that it fits as best it can with the enterprise IT direction – make rational compromises, make sure that IT and business management understand the compromises (this also builds credibility as business aware pragmatists)
  • Keep tabs on delivery in a non intrusive, non obstructive, non policing way e.g. be available to give advice throughout delivery, be a “free” additional project resource
  • Be present at the post implementation review and benefits review (if your organisation doesn’t have them then organise them!)

Get some artefacts
In this case, we had more artefacts than we needed. We had to make them digestible, intelligible and interesting to our customers who were not architects. A three inch thick document making technical recommendations can be reduced to a single page with the decisions. Our work was finding the relevant facts for each of our customers at each stage of the process.

In other organizations, I have started with no artifacts. That didn’t stop us working with projects, we just delivered the key artifacts that we needed as we went along. You may have to work long hours but you don’t waste your time producing superfluous documents.

However many architectural artefacts you have there will always be a job to identify what is appropriate for your audience and to create or customise a deliverable to meet their needs.

How did we do?
We moved from academia to providing value to projects and securing service delivery inside 2 months. Five of the right architects were delivering more value than a team of 17 had previously. It’s not about numbers; it’s about the right people doing the right thing.