Peter has several other slideshows that are well worth a look.
]]>There is also a good list of enterprise architecture blogs on the site which are well worth browsing.
]]>This list is not complete, so please feel free to let me know of any more models and to provide feedback based on experience of using the models...
]]>Peter has several other slideshows that are well worth a look.
]]>I am going to state the obvious – most people look at documents and diagrams on screens or on printouts that they carry around. The size of these is pretty consistent at around A4 size. If you cannot read and understand a diagram that is that size then the diagram is a waste of effort. So, please have some consideration for your audience when creating diagrams – it is a simple and common courtesy.
But I said it is “bad architecture”, surely this is bad presentation. First, since communication is critical for architects, then poor communication is bad architecture. However, the point is deeper than this…
Good architecture is well modularised. It is separable logically. A large complex domain can be decomposed into multiple simpler domains with clean simple interfaces between them. This implies that a set of hierarchical diagrams can be created to represent the architecture each of which can be understood on their own and with sufficient contextual information. So, going back to the communication point. If the architecture is good then it can be presented simply. Is there any benefit in making simplicity appear complex?
What about the as-is? If the current architecture is a mess of spaghetti then how can this be represented simply. Well, this is a core part of the architecture skillset! Logical partitioning is a critical step towards resolving the mess. In short, you must partition it logically as you would a good to-be architecture and what you will be showing is that interfaces are not clean and the components are not well formed. This gives you a start point for refactoring. Showing a mess by producing complex diagrams highlights the problem but does not help solve it.
Please don’t produce complex diagrams, there is no need, ever! I do not want to waste my time trying to understand another diagram with 200 blobs and 500 lines on my laptop again. The person who produced this diagram had the knowledge and has singularly failed to transfer it effectively. That is bad architecture and failure for an architect!
]]>Architecture is about doing the right things right.
In general, we understand that we support strategic, project and program decision making to help the organization understand what the right things to do. We understand that we must perform a technical guidance and governance role to ensure that the right things are done in the right way.
We often fail to understand the scope and scale of these activities. They are not minor side activities; they are not things to be done in spare time. Once we have any sort of architectural direction, they must be the main focus of our activity and the main usage of resource. Let's be clear, if we are spending more than 50% of architecture time is spent on creation of architectural artifacts then we have it wrong.
What should we be doing? We need to focus on the “lines”. How do we use our architectural artifacts and our knowledge to support our immediate customers i.e. the strategic, program and project management, and the delivery teams.
First, the organization or the program or the project must spend money on doing what is right. It is the management and governance structure that makes these decisions. These decisions take place at a number of levels:
Strategy – what business are we in? What are our core competencies? How do we structure ourselves? What products and services do we offer? Who are customers? How do we interact with customers and partners? This is where business architecture is critical.
IT governance – what is the IT strategy? What is the sourcing strategy? What is the project and program portfolio? What application and service portfolio is required? How much can IT spend on delivery? What services levels are required? Enterprise wide IT architecture and business architecture drive these decisions. Service delivery escalations.
Program and Portfolio Management – what is the correct scope for a project? What are the major milestones? What are the relationships between projects? What is the correct management structure? Project and program escalations.
Business Change Planning – What pace of change can the business achieve? Is business and IT change fully aligned? Is there effective communication between the business and IT to ensure change remains aligned?
Application and Infrastructure Landscape Management – Is the IT landscape changing to meet business needs? What constraints does the IT landscape impose on the business? What business risk does the business dependency on IT create?
Information and Data Governance – Are master data management business processes effective? What impact does poor master data have on the business? Is data quality managed effectively? What information do people need to do their jobs effectively? What value does business intelligence add to the business?
Carrying out these activities effectively depends on having architectural artifacts in place. However, the value of the artifacts is in the communication and analysis of them in order to answer business questions.
Once the organization decides to do the right thing, it needs to deliver it and deliver it right:
Program Delivery Support – What are the business and IT dependencies? What are the business and IT risks? What are the correct mitigations? What are correct delivery lifecycles for each workstream? How can the timelines for each workstream be aligned? What risks and issues should be escalated?
Business Release and Change Management – an IT release will require a stream of business change activities that will need to be synchronized with the IT capability that is delivered. Any change from the business or IT side will require an impact analysis and a re-synchronization.
Design Support – business and IT delivery teams must understand what, when, how, why, and where to use apply different tools, techniques, patterns, standards, processes, etc. Support must be easily accessible, timely, friendly and impose a minimal overhead.
Delivery Process Oversight – delivery effectiveness and efficiency are bound up with delivery excellence at the detail level. When the crunch comes, project timelines and costs will often take precedence over architecture. Effective architects ensure that good delivery processes (e.g. estimating, configuration management, release management, resourcing) are in place and followed. This reduces the possibility of time and cost pressures causing architecture to be compromised. For this to be effective, this role must be carried out sensitively.
Service Delivery Oversight – architecture is delivered through production processes and systems. It always amazes me how few architects get out to the sharp end of delivery and experience reality. Architects need to be closely involved in escalations, major incidents, key risk and issue management, critical dependency and assumption management, and change control. This ensures that architects remain grounded and they have an influence on the real world fixes that potentially will compromise the architecture.
Business and Technical Design Authority – as David Linthicum says “you must have some kind of hammer to drop on somebody's head”. Ideally, you should never have to use it. By successfully executing the supportive approaches above, the design authority role is a confirmation that architecture has been applied correctly or deviated from appropriately. There will of course be some unplanned deviations.
For enterprise architecture to be a success then it is critical that the main emphasis is on the collaborative activities that apply the core architecture artefacts to business and IT delivery. This allows value to be demonstrated, it leverages the expertise of the architects into business change and business operations. Perhaps more importantly, it leverages the expertise of those in the business and IT who are at the sharp end to ensure that enterprise architecture is relevant, useful and actioned.
]]>I noticed that, in order to assimilate this information, he took the same approach that I did which was to abstract the information upwards into a single simple diagram that captured the entire architecture in about seven blobs. He then took each blob and exploded this into further diagrams each with about seven blobs until he had an understanding of the problem area. The result was a concise and easily comprehensible story at increasing levels of detail that was easier to follow and understand than the original.
We had a discussion about this and noted that in our experience we rarely see architects develop simple sequences of structured diagrams that tell a comprehensible and compelling story. Instead we see diagrams with confusing inconsistencies in style and far too much information. A set of diagrams should tell a story - there should be an obvious start, middle and end. They should stand alone without the need for a narrator - a picture should not require a thousand words to explain it.
Rather than put my own tips for diagramming, I have deferred to an expert and added a link on the site to "Whiteboards that Work” by Bill Branson which contains a range of communication best practices.
]]>From my European perspective, this is an odd debate. I have the impression that a lot more money has gone in to enterprise architecture over the last 10 years in the USA particularly from government. Obviously, this has not been the case across the board but the struggling American architecture manager has not had a very high profile.
If you have millions of dollars and years to deliver then what pressure is there to be pragmatic? This has meant that the dominant approaches to Enterprise Architecture are Big Architecture Up Front approaches. Where architecture has had less acceptance and less money, we have had to evolve alternative ways of achieving our goals. We have had to develop creative approaches to making our money go further.
If I am right then, what we may be seeing in action is natural selection. Perhaps the reason that we can move ahead more quickly with SOA is that we are more focused on delivering benefits, we have had to be more pragmatic, and we have had to work out how to move incrementally down a strategic path. Because we have been under greater environmental stress, we have evolved enhanced capabilities to manage architecture effectively, to demonstrate its direct business benefits and now our SOA initiatives are reaping the benefits.
]]>You probably know why I find it tough to recruit now!
Chief Architect
Do you want more of the same? If the answer is “yes” then you have to evaluate whether your organization can give it. Often, an organization will pause for a couple of years after a major change before engaging on the next round. What will your role be during this “steady state” period? Will you be positioned correctly when the change kicks off? Your experience will tell you that those discussions are already happening – are you involved in them now or can you get involved? If you don’t shape the change from its inception then the chief architect next time around may be a consultant or an “outsider”.
Alternatively, you talk to the head-hunters. You follow up on some of their opportunities. Invariably, the roles are smaller, your compensation expectations are too high, you don’t believe in your potential new boss, moving away from home doesn't suit, or the role just doesn't excite you.
You are in a box as a “chief architect”. But, as an experienced chief architect, you have a huge amount of senior level business and IT experience that looks like it is about to go to waste. Maybe, you should look at alternatives…
Head of Architecture
Sometimes, the Head of Architecture and the chief architect are different people. The difference is that the chief architect is “responsible” and the Head of Architecture is “accountable”. The chief architect reports to the Head of Architecture who is typically on the senior management team of IT and sometimes of the organization.
The Head of Architecture is a manager (and hopefully a leader). They should be a business person first and an architect second. The Head of Architecture faces outwards into the business and into the management organization. They drive architecture to deliver for the business. They create the space for architecture to be effective. It is a political role.
The extensive knowledge of architecture that being a chief architect provides is vital knowledge. But the key capabilities are the business, management, leadership and political skills that will have been developed in driving through successful organizational change.
If you want to make the switch, then you need to have your eyes open to the different emphasis of your role. Not all your staff or management team peers or even your boss may understand the difference in the roles. There may be pressure for you to be the chief architect and also the head of architecture. I don’t believe that this is sustainable; I have talked about architecture being led by a two headed monster elsewhere. It is a balancing act.
CTO
What is a CTO?
Anton Chuvakin uses this definition …
"the great CTOs usually can’t manage their way out of a paper bag, but
The paper "The Role of the CTO: Four Models for Success" by Tom Berray and Raj Sampath identifies these types...
Each of these roles may be a valid direction for a chief architect. They each exercise different aspects of the talents of a chief architect. The roles have a level of management and politics that may deter some architects. The move should be quite easy. It is important to understand what is required and whether you can adapt and are a good fit to the requirement.
CIO
The CIO is typically the head of IT for an organization and will the normal management responsibilities that a head of function will have. The IT leadership role that ensures that the IT function delivers the needs of the organization.
The leadership role has four key dimensions:
A chief architect moving into a CIO position has to be aware of that these four dimensions have been listed in priority order. If you find operational delivery or maintenance issues tedious then don't do this job. It doesn't matter whether the head-hunter or advert stated that a change agent was required - fail on operations and you get fired.
An astute organization recruiting for a CIO will ensure that the new CIO can cover all the bases. This can be a problem for a chief architect since often they don't have strong operational experience and may have moved out of project delivery management some time ago. Moving sideways may be an option...
Head of Development
How many people have you managed? What was the value of the projects that you managed? How many projects in your portfolio? Tell me about your project management experience?
The normal route to head of development would be through project management and technology resource management rather than architecture. Do you have a good story?
In some organizations, the architects are the enemy. Can you overcome the potential prejudice?
This can be a very good move. You get the delivery management, you get a large part of the function management, and you continue to be involved in business change. If you are sensible you get close to operations, you ensure successful transition, you take operational failure as your failure, you ensure exception processes and procedures are implemented to deliver operational success.
Program Management
For some architects, a sideways move to program management can be attractive. Work on large programs as design authority, project management experience and significant business stakeholder engagement are prerequisites for this to be a realistic option.
To make the move, add a program management certification. It is useful to have shadowed a program manager or program director on a major change program to get credible hands on experience. This can be coupled with a design authority role.
The first role may not be that challenging unless you can be seen as the successor to an existing program manager or director. But being seen as delivering major business change successfully will open lucrative doors.
Business Change Management
If you are a more business focused architect and have concentrate on business processes, operating models, and requirements rather than technology then business change management may be an option.
You will need to have worked your models through to implementation and be comfortable working with real end users - e.g. are you comfortable in a call center or at a checkout. Have you "walked the floor" on go live day? Have trained end users in their new ERP? Have you worked through the issues of instilling the process disciplines necessary to to operate an enterprise application successfully.
You will also need to be comfortable working at all levels of management from VP to supervisor. Can you convince a VP committed to multi million dollar savings that a systems change cannot be implemented in a call centre just by shouting loudly? Can you identify the detail that breaks that concept, work out a solution that works on floor and delivers the benefits?
Architecture Consultancy
Most consultancies are in need of good architects and are seeing a lot of people in their efforts to recruit. If they like you then you are in a strong position. But you must ensure there is a good fit. Is the role right? Can you work with these people? Is what you like doing what is being sold? Can you find a way of working that fits your personal life?
The consultancies very often split enterprise architecture into different practices. Business architecture will often fall into a general business strategy practice and domain based consulting. IT architecture is also often split into IT Strategy and technology architecture. This can pose a problem for the enterprise architect who wishes to link business and IT.
You will need to understand the practice structure, how the practices work together and how they engage with clients both pre and post sales. It is important to understand what areas of architecture interest and motivate you. You must make it clear to your interviewers what these are and how your interests work effectively with the way the consultancy operates. If you can't work this out, walk away. If you are not convinced that the interviewer understands and can make it happen, walk away.
If you are convinced that you can make it work then you have to get into the practice that positions you best. You will have to build relationships with the other architecture related practices, the delivery practices and the sales people in order to create success for yourself.
Or a complete change...
Alternatively, you may wish to get out completely and become a priest, a lawyer, a day trader, a farmer, a property developer, or anything else that appeals. If you want a complete change then I wish you well ...