Chief Architect

New Blog Site...

2007-03-01T20:21:00.000Z

I have moved my blog to SquareSpace to take advantage of the more powerful features.

EA Management Rants has been split into 3 blogs...

Enterprise Architecture
Management
Career Decisions

Please take a look...

Enterprise Architecture Reporting Lines

2006-11-04T22:14:00.000Z

It is mainstream to have an architecture function in IT but its reporting line has not been finalized. I have seen most possible options and I have some views on what works and what doesn’t.

First, why do reporting lines matter? The enterprise architecture is an influencing, guiding and control function for IT. Its remit covers the delivery of applications, data and infrastructure. Enterprise architects need to avoid a conflict of interest with their boss otherwise their advice and decisions may be skewed by political considerations. Additionally, such a conflict of interest can result in information to and from the enterprise architecture team being filtered by the boss. Suppliers, business areas and projects may choose to take their guidance from the boss who is not an enterprise architect and not qualified to give the advice. The position of enterprise architecture gives a message of its importance to IT and the organization.

Let's forget putting EA in the Business. While the business gets benefits from EA, they are most visible in IT and IT hurts the most when it is not there.

A fairly common practice is to make EA report into development. In my opinion, this is worst practice. The head of development will have an objective that says “to deliver projects on time, on budget, that meet requirements and that conform to the architecture”. If EA is part of development, the architecture constraint is under the direct control of the head of development. The other objectives are not, which one is easiest to flex?

Reporting to service delivery has similar problems since service delivery will be changing the infrastructure. Its objective is “to deliver services that meet SLAs within budget and that conform to the architecture”.

IT strategy is about determining the business objectives for IT, putting together a high level IT change plan, and getting this funded. This is about what IT should deliver to the business. EA is about finding solutions to these requirements. “What” and “how are naturally in tension. This tension needs to be managed objectively. Sometimes objectives need to give, other times solutions. If EA reports into IT strategy then IT strategy becomes dominant. The likelihood is that considerations such as TCO will be lost to short termism. IT strategy and EA should be peers.

The ideal reporting line for EA managers is to report into the CIO. This gives influence and gives the EA manager a shot at the top job. Is it right for the CIO? Only if the EA manager can take a broad business view and contribute to the general running of IT. If the EA manager is a purist, a pendant, or a techie rather than a good general manager then the EA manager will soon lose influence and subsequently position.

The alternative to reporting to the CIO is to report into a more general control function which may include functions such as the program office, commercial management, IT strategy, risk and compliance. This gives the less experienced EA manager the opportunity to develop political and general management skills before butting heads with the big beasts at the CIO’s table.

Two Headed Beast

2006-11-04T22:11:00.000Z

When you look at corporate management, the typical structure is to have a chairman who faces out from the organisation towards the investors and a CEO who faces inwards and manages the organisation. Within organisations, you sometimes get a similar structure at board level. A board director such as a finance director or sales director who has significant outward facing responsibilities will be shadowed by a non board director or general manager who runs the operations for their division.

Is a similar management model appropriate for EA?

I have run three EA departments for large companies. In each case, I have identified a “number 2” who has had helped me very closely in all aspects of managing the department. Architects are experts in the their fields, sometimes considered mavericks, sometimes don’t suffer fools gladly, often considered difficult to manage by other managers. The continuing politic situations that EA finds itself both inside and outside the IT function can be complex and stressful particularly if there are major change programmes in progress. Sharing the management load has worked well for me. Other EA managers that I have known have adopted similar informal management approaches where a “number 2” has a special role in addition to being a member of the EA management team.

Is it time to formalise this approach? Is it time to recognise that EA management is a big job and that 2 heads are better than one? Should larger EA functions that are involved in large-scale change have a “two headed beast” leadership? The Head of EA would be the external leader managing the politics, driving stakeholder management, opening doors, top level supplier relations, and fighting the budgetary battles. Reporting into the Head of EA would be the General Manager of EA who would run the architecture teams identifying architecture needs, developing policy and models, supporting projects, etc.

Should IT include a business architecture function?

2006-10-18T15:14:00.000Z

I have had a couple of discussions recently about the place of Business Architecture in an organisation.

The first conversation was with the CIO of a Bank who asked me “Should IT include a business architecture function?” My response was that if the purpose of the business architecture function was to design the business operating model then “no”. If the purpose was to capture and formalise the business operating model then “possibly”.

A well-managed mature organisation will be continually re-evaluating its objectives, processes, external relations and structure. The function that carries out these activities may be called “strategy” or “business change” or something else but it is the business architecture function.

Ideally, this business architecture function will formalise the business design as a set of models. The operational business functions will take these high level models, develop them further, and create migration plans. With the IT function, they will identify areas for automation or changes to existing automation. The IT architecture function will develop a coordinated set of migration plans to deliver the required IT support.

In the real world, very few organisations operate like this. I have worked with one. The requirement for business change is not completely coordinated, it emerges in a somewhat haphazard manner, it is often not fully thought through, the objectives may not be explicit, political agendas will be accommodated.

In this case, clarifying the business operating model is essential if IT is to deliver effectively. The process will also resolve inconsistencies and anomalies in the business model. This becomes the role of business architecture within IT. It is not to design the business but to capture and formalise it.

A few days later, I was talking to the Business Architecture Manager of the insurance company that had implemented model-based business architecture as part of a business change function. She made me re-evaluate the conclusions above.

Her view was that, in general, business functions take a short-term view – the current budget, the next product release, the next marketing campaign, etc. At points where the senior management has come to the conclusion that a major business transformation is required they will put in place an business design function but this will be disbanded once the change has been delivered (sometimes earlier). Taking the short termist view, business architecture is not seen to deliver value.

Within IT, business architecture has clear value. It allows synergies between projects to be identified that save money, lower risk and deliver earlier. It allows IT impacts to be identified earlier and avoids expensive analysis errors. It allows business impacts to be identified so that systems changes roll out smoothly. The absence of business architecture means that TCO for IT will be higher.

This leads me to the conclusion that, business architecture as business design is unlikely to be viable as a business function. Business architecture as business design clarification and formalisation is a necessary IT function.

Outsourcing Consultants

2006-09-24T08:22:00.000Z

I recently discovered a report on the Deloitte web site called
Calling a Change in the Outsourcing Market - The Realities for the World’s Largest Organizations.

Its findings were that very often the deals failed to meet their objectives:

70% cited cost savings as a key driver for outsourcing, but 38% said they ended up paying hidden or added costs they thought were included in their contracts.

57% cited quality and innovation, but 31% said vendors became complacent once contracts were in place.

35% cited flexibility and capacity, but comments revealed that contracts are binding and vendors, often rigid, are refusing to accommodate last-minute changes.

22% cited access to high-caliber labor, but one in five experienced greater employee turnover and realized the intellectual capital they had paid for was fleeting.

22% cited transfer of risk to vendors, but they said vendors were unable to fully absorb the costs of business losses, leaving the company on the hook for paying the bill.

16% said they outsourced because they lacked the in-house expertise, but 44% found their vendors couldn't deliver on the quality and cost savings and they decided to bring the operations back in-house.

These findings were backed by reports from Dun & Bradstreet and DiamondCluster International. The report received a lot of attention at the time which can be found by searching so I don’t want to go over that. I want to make another related point…

If you are engaged in outsourcing, then it is very likely that you will use an outsourcing consultancy. The selling point of these consultancies is that their consultants have “been there and done it”. This means that they were probably responsible for some of the catalogue of failed outsource deals highlighted in the various reports. Do you really want to be listening to these guys? Do you want “common practice” or “best practice”?

A short journey in a taxi

2006-09-08T13:04:00.000Z

I had just finished a reference visit and I got into a cab to take me back to my hotel. For the first half of the journey the driver was silent. He drove with one hand on the wheel and the other out of the window. I became aware of sudden jerky movements out of the corner of my eye, the hand that was out of the window was twitching.

Five minutes into the journey, the driver asked me where I was from. I told him and he said, “I went there 30 years ago as a kid”. He then said, “I’ve been through there on a train to an interview”. He had been to a lot of interviews in a lot of places. I surmised that these must have been university admissions interviews.

I began to get worried when he said that he had lost going to one interview because “I’m not very good at finding places”.

He didn’t get the grades, he was going to retake his exams but he had a nervous breakdown. He got a job delivering milk. He wanted to do day release classes but his employer would not give him time off. He had an opportunity to take a job with prospects at an insurance company but it didn’t pay enough. He then became a taxi driver. His ambition now is to retire at 50.

He said, “You might think it’s a waste of a life but I know it’s not my fault”.

I asked him, “What will you do when you are free and clear”. “I have thought about counselling, I’m interested in counselling. I would like to take a counselling course.” I said, “There are always people who need help”. He responded, “But I would want to know if there was a job at the end”. I said, “I’m sure the charity sector would have opportunities which you could do if you were retired”.

He paused, took a breath, twitched a couple times, put both hands on the wheel and gripped it tightly as memories came back. “I went for a position once, they rejected me. They asked me about my family, I told them that I had a sister who was a jerk. I probably didn’t make it clear enough that I am quite capable of working with jerks and idiots without prejudging them.”

At this point he slowed down, relaxed his grip, put one hand out of the window, gave a small twitch, looked around, then said, “I’ve taken a wrong turn but I can get you there without going too much further.”

A few moments later, the hotel came into view. I was silent. He said, “You might think it’s a waste of a life but I have the satisfaction of knowing it’s not my fault”.

The Next Evolution: Enterprise Architecture Guidance

2006-09-04T19:44:00.000Z

The Next Evolution: Enterprise Architecture Guidance
Tom Rose has written a very kind entry on his Blog Site about us. Please visit his blog site, The Next Evolution, for considered thoughts and advice on Enterprise Architecture, RFID, Sensor Networks, Near Field Communication, WiMax, Web 2.0, SOA, and other interesting related topics.

Enterprise Architecture Management Styles

2006-09-03T09:03:00.000Z

I have worked as an enterprise architecture consultant and an architecture manager in a large number of major organizations and observed many different styles of managing enterprise architecture. A typical department will use two or three of the styles listed, there may be a need to adopt different styles because of changing business goals or previous performance.
Big Architecture or “Let’s populate the Zachman Framework”
John Zachman’s argument that you have to plan before you do and that you need a view across the whole enterprise is compelling. However, how much of a plan do you need and how much of a view do you need? The answer is in column 6, row 1. The strategy of the organization should drive our efforts. The strategy will contain objectives, a statement of its appetite for risk, the timetable for achievement of the goals and the investment it is prepared to make. Architectural efforts must align and produce only the artifacts geared to strategy delivery. If the timescales are tight or money short, then we must be pragmatic and compromise.

However, what often happens is that the objective becomes populate the Zachman Framework for the entire enterprise. Each cell generates a task to create an “As-Is” model and a task to create a “To-Be” model. Each column is taken and given to an architect. Someone is sent off to find out what the business strategy is to populate column 6, row 1. The answer isn’t understood and there aren’t any standards for modeling strategy, so “best practice” becomes the guide for producing all the “To-Be” models. This isn’t arrogant, of course, because it is based on logic.

After nine months, this exercise in intellectual indulgence and data gathering is cancelled due to the lack of any obvious benefits emerging.
Transformational Architecture
Sometimes, the organization has a “big idea”, a transformation, a merger, a shared services structure, a major change of some sort that requires major investment in IT. The case for architecture is easy … Big change = big design = architecture.

A business transformation places “big architecture” in a clear context with clear objectives and timescales. It gives direction, visibility and urgency.

A major issue for architecture is keeping close enough to the business change to design a solution that meets the needs and has a feasible migration path. Get behind the curve and the consultants and vendors fill the vacuum with half baked solutions that you spend the next 5 years unraveling because they were poorly architected. Get too far ahead and you get accused of trying to bend the business to fit your own pet scheme. Highlight too many problems and you are seen to be “off message”.

How do you get involved? This comes down to influence, relationships and politics because you have no right to be there. Do some stakeholder analysis and plan a campaign to raise your profile in a sophisticated manner that gives credibility and influence as a business person who is worth listening to.
Project Architecture
As far as I am concerned the concept of an enterprise architect being controlled by a project is nonsense. The job title may include the word “architect” but it is not architecture if the project manager has control of the architect – role is actually a design role. A fundamental part of architecture is that architecting concerns balancing competing demands between projects, between long term and short term objectives, and between different areas of the enterprise. There is a conflict of interest if the project manager controls the architect.

Should architects be allocated to projects? Yes, but only when necessary. When is necessary? When the project may decisions, through pressure of objectives or through ignorance, that pose a significant threat to enterprise business goals. If there is no risk, then there is no need for architectural involvement.

In practice, there is always some risk. There are also constraints on resources, so risk drives the level of involvement required. A triage process is essential to identify up front where to put resources, and integrating architecture into the development process means that you should never lose a project.
Program Architecture
A transformation involves the whole business, doing transformational architecture is by definition enterprise scope. A program typically has a single business theme, e.g. customer service, which has a narrower scope and impact.

Program architecture is a mix between transformational involvement and project involvement. Architects work across the projects within the program to deliver program objectives. They also have a role to ensure that the program follows the enterprise agenda not the program agenda if it differs.
Portfolio Architecture
A program is a set of projects that are related at a business level and it is clear that there are significant interdependencies. A portfolio is a set of projects that are managed together for convenience, it may they share a resource pool or a set of business managers. But from a business point of view they are seen as largely independent.

The project management approach is typically to treat these projects as independent from a deliverables perspective but resource constrained. However, the reality is that they are likely to be using the same data, programs or infrastructure.

The architectural task is to carry out a technical impact analysis to understand where different projects hit the same IT asset. Databases and programs should be changed a minimum number of times to minimum costs and risk. Infrastructural changes need to planned as a single exercise to leverage shared infrastructure and to minimize procurement and implementation costs.

This puts timescale and resource constraints into the projects but it achieves greater quality and lower costs. You just have to persuade the project managers and the portfolio board of this.
Operational Architecture
The management styles discussed so far have focused on projects as the locus of architectural activity. There are other approaches based around service delivery.

Being service delivery oriented they have clearer and quicker paybacks. However, the skills base and interests of those typically in architecture roles often does not sit well with such an orientation.

An example of an operational architecture objective would be “reduce helpdesk calls”. If there are 10,000 calls a month and each call costs the IT function $25, then a 20% brings a cost benefit of $600,000 potentially realized by reducing IT headcount or reducing the need for contractors. The business benefit is much higher because each call is lost time to the organization which may mean increased operational costs or lost revenue. My team delivered this within 2 months by reviewing the use of the helpdesk system, implementing better solutions for frequent calls, and redesigning end to end processes. Was this IT focused? No, the organization gets an improved IT service which means it can use its resources to meet its objectives rather than to deal with IT problems.

Other examples could be:

identify and eliminate repeated problems

reduce release failures

reduce call outs

improve application performance

improve security

demise expensive platforms

improve business intelligence

speed up the turn around of small changes

The common feature is that the actions are within IT and visible results can be delivered within weeks to the organization.

My view is that this is the best place to start enterprise architecture. Too often architects start with big ideas and fail to deliver them. They naively believe that the organization will wait years for the evidence of the benefit to become clear.

Operational architecture is about getting IT’s house in order before pushing the business to do the same. It is about taking the medicine within IT before exposing the business to its rigors. It is about proving the value for money of an enterprise architecture team. It is about delivering tangible benefits to the organization in terms of improved IT service delivery and reduced IT costs. Six months of solid operational architecture performance gives credibility and a great foundation for extending the architectural objectives into the organization.
Procurement Oriented Architecture
Procurement oriented architecture focuses on the purchases that the IT function makes and attempts to optimize them from a financial point of view. Architects review application and infrastructure purchases.

With applications, reuse or extension of existing in house or licensed applications will typically be advised if possible. Minimizing the number of suppliers is also often a goal. The pitfalls are shoehorning needs into inappropriate applications and some suppliers terms have financial “steps” in them that make further licenses prohibitively expensive.

With infrastructure, consolidation is the key to minimizing costs which requires a good knowledge of capacity needs and actual performance. Infrastructure costs typically have financial “steps” which can be exploited. For example, my team saved $5M on an $8M proposal by changing the required spec from 3 top end servers to 5 mid range servers. Did the supplier like it? No. Did they offer the lower range solution? No. We had to do the detail to work out that our requirements could be met by the lower spec machines. The small amount of added complexity and marginally lower flexibility were not worth $5M.

Like operational architecture, this approach is largely confined to within IT but does have significant measurable benefits that can form a foundation for extending architectural work.
Policy Architecture
Architecture policies are the practical instructions for the implementation of architecture principles. They instruct those delivering applications and infrastructure on what they must deliver. They may also set out SLAs or contracts with the business e.g. for data quality.

Some architecture departments’ primary mode of governance of the IT function in relation to architecture policies. This is the creation and maintenance of policies, guidance on policies, policing the process, approving documents, issuing waivers, etc.

This is a very dry role. There is creativity in the research the goes into the formulation of a policy. There is human interaction in the dissemination and mentoring that goes into supporting policies. But often, the architecture function slips either into a police force or to a burdensome bureaucracy.

Sometimes this model is imposed, for example, by the group company on a subsidiary. In this case, efforts must be made to make the approach user-friendly. Architects should guide and support projects so that they automatically comply. They should identify the need for a waiver early and sponsor it. Project managers need to understand the impact of compliance on their projects so that their estimates take any adverse impacts into account. The rationale behind policies should be explained.
Model Based Architecture
The aim of model based architecture is to create models in the hope that they will prove useful. Unfortunately, the usage is often not clearly defined. This means that the models don’t have a real purpose, they don’t have an audience. The result is that they are not built to be used. They become write only models.

I have had to disband two architecture teams in my time that had got into this situation. It is unfortunate because the architects involved had put such a lot of effort and intellectual energy into the models. But, the models were essentially useless because they had no purpose and were unintelligible to anyone but the authors. The authors had got themselves into a place where they did not appreciate that their audience needed some consideration. The emotional attachment of the architects to the models made them useless as architects.

Models are tools for architects to do their jobs working with business and IT management and staff to achieve benefits for the organization in line with the objectives of the organization. Models are not an end in themselves.
Silo Based Architecture
A pet hate of mine is to divide architects into business architects, technical architects, data architects, infrastructure architects, solution architects, project architects, etc. It creates silos where the architectures don’t connect.

The application direction is intimately related to the process direction and the data direction and the infrastructure. We can’t pretend that they independent and set up different teams to work on each area separately.

Architects obviously have competencies and preferences in different areas but they must be able to operate competently across all domains otherwise they are not architects.

Another type of silo based architecture organization is to align with the business unit structure. This can result in architecture reinforcing business silos and fundamentally failing to support the enterprise agenda.

How do I organize? I operate a very fluid and flexible structure. I have two tier teams. One tier is the more experienced architects who are capable of running an initiative. Some of the architects have ongoing roles as single points of contact. The rest of the architects form the other tier.

I continually form and reform teams to address specific needs typically the structure changes every few weeks. Each person is generally in 2 or 3 teams simultaneously. Sometimes the teams include people from the business or from other IT areas.

My role is to make sure the approach is working, rebalance the load as necessary, set priorities, and to mentor all the architects to ensure they can deliver to each of the initiatives they are working on.
Opportunistic Architecture
When money is tight in an organization, architecture has a hard time. The number of architects is generally reduced, sometimes to zero. If architecture is still recognized as adding value then as architects we need to take the small opportunities that exist.

This means getting smart over communication. A typical architecture message is about strategy, the long term, flexibility, etc. An organization that has constrained investment is usually looking at short term actions to survive – the strategy is not to spend unnecessarily, the long term will be taken care if we get there. Architects need to get “on message” or lose credibility.

We have to get smart with payback, the organization is looking for rapid payback – 3 months, 6 months, definitely less than 12 months. Therefore, long projects are out, incremental delivery is in. Do something, get some payback, do some more, get some more payback, bring the benefits forwards. Doing this you are helping your organization meet its strategic need to survive, you are showing that you business savvy, you bringing forward the day when the investment constraints get lifted.

We have to get smart with suppliers. Some suppliers will play ball and use value based pricing. This means that they paid based on the value that you receive rather than the capability of the product i.e. you buy a strategic product that gives you a foundation for the future but only pay for what you use. The supplier wins because when you expand usage they additional revenue with minimal presales effort. You win because you get an architecturally sound base to build on. But, you need to get price protection on your future usage so you don’t get screwed on licenses or maintenance.

We have to get smart with projects. You are trying to get each project to put in place a small number of building blocks for the future. You need to persuade them that this is at no extra cost and requires no extra time – they are under pressure. You need a very clear vision, it needs to be pragmatic. If it’s too complex or too big then the small steps will give you too little progress.
Guerrilla Architecture
When you get down to zero and architecture is not seen to add value then the only thing left is guerilla action. You have to be opportunistic but you can’t do it openly. You may also have to resort to sabotage where short term parochial actions are damaging the organization.

You are now playing a dangerous political game. You are exploiting failures to promote more thoughtful planning. You are chipping away at the credibility of others who may have more power than you. You fail if you don’t survive.

You are the one who says “I told you so” and then have a recovery plan. You are the lone voice in the wilderness. Sometime in the future, people will realize and understand that you were right. These people are politicians so they will take your ideas and claim them for themselves. They may even try and discredit you.

Guerilla action is not easy, you will likely lose. But hey, you had already lost, guerilla architecture is a way of retaining your integrity and maybe there is a slim chance of winning.

Get Out There!

2006-08-27T08:35:00.000Z

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.

Its not about Numbers

2006-08-05T22:01:00.000Z

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?

Get the right people

Understand your customer

Get a process

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 savvy 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 organization doesn’t have them then organize them!)

The TOGAF ADM will do!

Get some artifacts
In this case, we had more artifacts 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 well endowed you are with architectural artifacts, there will always be a job to identify what is appropriate for your audience and to create or customize 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.

Absence of Strategy

2006-08-04T20:56:00.000Z

What do you do if the business has not articulated any objectives for IT? What do you do if the business strategy has not been clearly articulated?

The following short examples show that high level objectives for IT can be identified in a variety of business contexts where there is no clear steer for IT. The process of deriving objectives and working through them with the business will clarify the role of IT.

Case example

Industry - Retail

Business Context - Struggling retailer looking for a buyer

IT Context - legacy applications, aging infrastructure