www.flickr.com
This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace
« Enterprise Architecture Management Styles | Main | It's not about numbers »
Sunday
Aug272006

Get out there!

Enterprise architects are often accused of “living in ivory towers”. They complain that there 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 delivery of architecture – and we must always remember “architecture is pointless without delivery”.

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 guidance. This means that architects must have credibility when they advise on 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 reality of the IT service that we have architected. We need to see how we have succeeded or failed. Our conversations with business managers and in IT will 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 process improvement. I want my architects talking to the Strategy Director about business intelligence. 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 or the high level design has been communicated. If you do it will be 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 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.

 

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (2)

At 9/03/2006 05:14:00 PM, Tom Rose said...

An exceptional message and one that is hard for many architects to execute. I can also confirm from the trenches of enterprise architecture that this is what brings the value of architecture to the enterprise. It’s about selling it from the server engineer racking a 4-way to the CEO, and while you are selling it you are delivering it project by project. The reality, bringing architecture to the enterprise is almost never about glorious or grandiose projects. It’s a slow and methodical adoption of architectural guidance by business and IT; essentially the goals of both become one.

The difficult part is the 360 degree buy-in required; and while getting enough execs, business, and IT operations staff to understand by achieving project successes, it’s frustrating to everyone involved for a very long time. Especially, while the architects are moping up messes all over the enterprise, otherwise known as “projects where success was declared, and kudos were had by all.” The technical and business operations aspects of enterprise architecture are easy, relative to the marketing campaign that has to be sustained.

Your have a very powerful message that every architect should embrace. Perhaps soon, architects can guide their enterprises to the state of maximizing operating efficiencies, so they can focus on the more exciting tasks of innovation to drive revenues.


Best Regards,

Tom Rose

(from the original blog site)

February 15, 2007 | Unregistered CommenterAlan Inglis

My own observation about the Software Architects is that they want to live on the 'ivory tower'. Many pretend to be busy and do not want to spend time in understanding the business strategy. So your recommendation for the architects to get out there with other managers is very relevant. Some Architects are not good with verbal communication and have difficulty explaining the business benefits of some of the cutting edge technologies. The non technical managers get that kind of information from the sales people of vendor organizations during trade groups/ conferences. Software Architects cap play a role here to influence the business managers with the right application selection (need to talk in terms of ROI and TCO etc).

August 21, 2007 | Unregistered CommenterRaj Sheelvant

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>