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 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. 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.
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
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 inter-dependencies. 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 deliverable 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
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 help desk 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
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.
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, re-balance 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.
[Ref: http://chiefarchitect.squarespace.com]
