jump to navigation

Why do we need architects anyway? February 10, 2013

Posted by Chris Eaton in architect, architecture, architecture method, artitecture, careers, communications, competitive strategy, EA, Enterprise Architecture, IT Architecture, IT strategy, methodology, methods, people.
Tags: ,
add a comment

I recently spent a very interesting day with IBM and the Corporate Executive Board on the future of architecture. Very interesting, very thought provoking. On the back of this, i have put together this paper Why do we need IT architects anyway?

‘The pervasive nature and continual improvement of technology in daily life presents vast opportunity but it is not always easy to see it. Armed with the right skills, methods and tools the IT architect can help you see the possibilities and exploit them’

Thoughts and comments are welcome. And i am very interested in how you live up to this vision…

Business operational architect February 6, 2012

Posted by Chris Eaton in architecture, Enterprise Architecture, methodology, methods, people, profession.
Tags: , ,

funny how time flys…200+ days since i made a post. Hard to believe it!  t’has been a busy time

One idea I have become very interested in recently is the idea of a Business Operations Architect (better names may exist!).

Let me explain this role. I am very interested if this role exists in organisations already and what i might learn from them

My starting hypothesis is:

  • most architects are working on project delivery, architecting new solutions or upgrades to existing ones. Typically they introduce new functionality to end users (business, application or functional architect)
  • some architects design infrastructure (technical or infrastructure architect)
  • some architects are working on Enterprise Architecture; they plan the future IT landscape of applications and infrastructure

No architects are looking at current applications, their functionality, infrastructure, incidints, problems and supporting environment such as monitoring, capacity, performance, etc .

Therefore: a new role is needed: the Business Operations Architects: they ask and answer the following questions:

  • Are users happy with the functionality? what needs to change to improve user experience and function?
  • What incidents have happened, how can they be prevented in future?
  • What problems exist in the current solution and how can we solve them with future releases?
  • Is the supporting operational infrastructure fit for purpose (monitoring, alerting, hardware type/age, software age/support arrangements and if not, what changes are necessary?

They would also play an assist role:

  • are new solutions fit for purpose; functionally and operationally? they would lead or participate in architecture reviews
  • ensure changes are accurately reflected to documentation such as system scope diagrams, interface specifications, architecture diagrams – these often are out of date relating to atrophy of design
  • provide expertise to support incidents and help restore service

is this a good idea, is anyone performing this role, does anyone have a better name for it!



who makes architectural decisions and a TOGAF rebellion June 30, 2011

Posted by Chris Eaton in architecture, architecture method, methods.
Tags: , , , ,

so i am a fan of the idea of architectural decisions – an architectural decision is the consideration of a problem which needs a soltion (most likely an it solution) and deciding and agreeing what to do

In my opinion, solving problems like this is the very essence of why architects exist because these problems do not often have obvious answers and there are multiple options to solving any particular given problem.

In the last month or so at work I have been looking at who decides which applications are strategic and which are not

I assumed this was a decision the Enterprise Architects made

Much to my suprise in over half of my organisation this decision is not made by people who call themselves architects at all. Instead this decision is owned by IT staff who have come from the business and now are in IT, and by Application Portfolio Managers / Application Managers.

Application Portfolio Management is a role not oft spoken of in the realms of architects but one everyone should be aware of. Application Managers typically own the operational running of a set of applications i.e. incidents, the projects, the cost and customer satisfaction of those applications. This this usually means they talk to the business very frequently about outages, incidents, projects, etc

Therefore adding on an accountability to determine whether an application is strategic or not is a very nature addition to this role. This is probably in consultation with architects but ultimately takes this decision away from the architect, if they every owned it in the first place

I have found this answer rather challenging

I had an assumption that architects would normally own this decision. They are typically technical experts with depth in one or more business domains. The most logical home for this decision

However, on reflection placing the accountability with an APM seems like a more natural home.
– they have a more holistic view of the application, its operational issues, projects in flight, customer satisfaction, cost
– they probably control the project and operational budget and can more easily make a more realistic determination about the ability of the organisation to make an investment or replacement of an existing application
– they do not need deep expertise, they can call on other expertise, most likely architects, to help with the decision but ultimately as the owner of a portfolio are the people who will have to deliver it. This gives a very healthy dose of reality and objectivity

if i put the TOGAF crop circle in front of an application manager, would they have the faintest clue what i was showing them or talking about?

the answer is almost certainly no

if i put the TOGAF crop circle in front of a business person, would they have the faintest clue what i was showing them or talking about?

absolutely not

so a togaf rebellion…

if I changed TOGAF to about analysis of requirements, design options, costs, benefits, value, implementation time, functionality, usability, and risks would they know what i was talking about?

yes they would

and so i am concluding that TOGAF is a method designed for architects by architects using an abstract and inaccessible language useful only to architects

in my opinion a new method is needed which business people can understand. They can understand that there are specific considerations to determining whether one IT solution versus another is better or not

im afraid terminology like Architecture contract, preliminary phase, and migration planning will never be part of a discussion with the business which i ever have

and perhaps thats why application managers are better placed to have accountability for architectural decisions than architects

is anyone interested in creating a method like the one i suggest, i cannot do it alone…

TOGAF 9 July 14, 2009

Posted by Chris Eaton in architecture, architecture method, artitecture, EA, IT Architecture, methodology, methods, people, Uncategorized.
Tags: , , ,
1 comment so far

the last 2 days i have been attending a TOGAF  course run by cap gemini who have made the majority contribution to the latest version of TOGAF

The good

so i learnt that many of my criticisms of TOGAF 8 have been addressed. Specifically it adds:

The Architecture Content Framework which is a library of prior architectures to stimulate reuse and reuse of best practice rather than reinventing the wheel

A meta-model which includes specific artifacts which result from each of the phases i.e. what you should produce and when, this was absent from TOGAF 8

An architecture capability framework which recognised that good architectures result from consistently trained architects with a high level of education and experience. At the end of the day your architectures will only be as good as the people who developed them

TOGAF is now more obviously applicable to solution architecture, when previously i saw it much more in the enterprise/strategic architecture space

The bad

the vapourware of the enterprise continuum remains this is still poorly described and arguably redundant. The continuum was always poor conceived and in-specific now it is super seeded by the Architecture #Content Framework, It is a such a shame the open group cannot shed this kind of legacy and have much stronger editorial process.

The Architecture Development Method still does not split out data and application architecture, this is stil bucketed under Information System Architecture,. Other areas of the open group like the IT Architect Certification recognising that these are separate significant activities. Again it seems the open group is so wedded to the ADM crop circle diagram it cannot, or will not, move forward and improve on prior thinking

The ugly

well nothing was that ugly to be honest, togaf version 9 is is definitely a step forward

how do I become an enterprise architect? May 14, 2009

Posted by Chris Eaton in architecture, artitecture, EA, mentoring, methods, people.
Tags: , , , , , , , , , , ,

in a recent discussion with a mentee the question was raised ‘what is the difference between solution and enterprise architect?’

My standard answer to this is to talk about the difference between cityplanners who think about city wide infrastructure and future objectives (enterprise architects) and architects of individual buildings who think about how the house is laid out, how strong roof supports need to be and whether their plan will fit to the city planners constraints.

the next question was, ‘ok how do i become a city planner?’

interestingly the city planner/building architect planner analogy does not answer this question, it simply states a comparison of job roles. So after a little thought here is my answer:

artITecture Skills Model

artITecture Skills Model


in essence as a developer (a specialist in IT) you know lots about a specific IT subject matter.  For instance you know how to write J2EE applications, test the code, deploy this into a container, use an integrated development environment and so on. Detailed stuff. In terms of exposure to different types of technology the experience is fairly narrow, working with specific technologies and probably with little care whether the solution is in a Human Resources, Finance, Supply Chain, Procurement and so on.

As a specialist you have some understanding of a particular business area but little thought or care for business strategy.

This growth in business and technical exposure leads to a point where there is a choice: remain specialised or loss the specialism and become more broadly focused – become an architect orchestrating the build but not directly building (rule of thumb says if your write code regularly you are probably not an architect).

Your sphere of influence is your code and immediate team.

Interpersonal skills are not so important as long as the code works!


Within the architect space the breadth of technical experience grows, but the hands on technical experience is shallow. On occasion deep dives return you to the specialist space.

You have the experience and credibility from the specialist experience to generalise, relate and guide specialists without ever having to have directly worked with the technology.

The trick here is to use specialists for their specialist skills, and bring this together at the solutions level.

In business terms you have probably medium to deep understanding in one or two or perhaps more business areas.

In strategic terms you probably have thought about business strategy within a business area i.e. Finance or Supply Chain, but probably not in a true enterprise sense.

Your sphere of influence is the other architects and technicians on your immediate project. You act as a consultant to key business and project management staff on your assigned project

Interpersonal skills are becoming increasingly important to communicate your ideas and sell them to your immediate project team.

In my own experience moving from a specialist to an architect I clearly decided my time with code was done, and i had a great model who i strong thought ‘i want to be like him and do the job he does’  I still count this role model as one of my best friends

The transition to an architect did stretch me, it was difficult to give up the security of specialisation but it was a decision i never regretted.

Enterprise Architect

you have very broad and shallow exposure to all kinds of technology and business area with depth in some areas. You have a good understanding of technology and technological concepts but the detail isnt of significant interest but the impact it can make is very interesting particularly how it could reduce the cost of doing business or differentiating the business in market.

In strategic terms, and for me this a key differentiator for Enterprise Architects, you have a good understanding of business strategy models (i.e. Porter), think in broad business and IT terms and can apply this knowledge to sell a vision of the future,  the benefits of the future vision and how it can be realistically achieved.

Interpersonal skills become a critical success factor especially negotiation and  influencing. Selling is probably the most important skill. It is required to achieve buy-in for visionary ‘to-be’ solutions at all levels of the business

Your sphere of influence is to aim for company wide impact through process or IT change and influence people who didnt even know they needed influencing!

My own experience of moving from architect to enterprise architect was similar to my transition from specialist to architect, i felt i was giving up a comfort blanket in business and technology architect specialisation for a very broad, perhaps somewhat inspecific role with an emphasis on strategic and inter personal skills, and not too emphasis on technology expertise – something which i had always seens as a personal strength and passion – but again i never regretted the move it was right at the time and i really enjoy the influencing aspects to my EA roles.

In summary, I hope it is clear that business, technology breadth and strategic business thinking is way to become an Enterprise architect, it will take work, it will take opportunity and a good dose of sponsership but in my view it is well worth it.

Architecture method template work products / artefacts March 24, 2009

Posted by Chris Eaton in architecture, architecture method, artitecture, IT Architecture, methodology, methods, total lifecycle thinking.
Tags: , , , , , , , , , , , , , , , , , , , , , , , , ,
1 comment so far

Following on from previous posts below are links to all the work products in the artITecture architecture method. The work products contain suggested formats and advice for completing them. The templates are intended to be just that; templates, customiseable to your own use.

Work Product Name Download Link
Architecture Decisions Link
Architecture Overview Diagrams Link
Architecture Risk and Mitigation Plan Link
Architecture Scope and Context Link
Change Cases Link
Component Architecture Link
Data Architecture Link
Decision Model Link
Functional Requirements Link
Infrastructure Architecture Link
Integration Architecture Link
Non Functional Requirements Link
Technology Assessment Link

Architecting for the complete systems lifecycle March 5, 2009

Posted by Chris Eaton in architecture, architecture method, artitecture, IT Architecture, methodology, methods, total lifecycle thinking.
Tags: , , , , , , , , , , , , ,
add a comment

Architecture is often focused on the implementation of a successful solution and it is easy to understand that the immediate concern of an architect and the project itself is to successfully go live.

I suspect that few (perhaps even zero!) architects or indeed project managers are incented on the long term success of the implementation and success of a solution over a number of years. The following diagram is my own version of the waterfall model.

systems lifecycle

The model looks pretty close to any other version of the waterfall model, but includes linkage to IT Strategy and Enterprise Architecture, and at the tail end to Service Delivery, Service Management and the eventual decommission of the system. The architectural thinking should included all these phases. The later end is often forgotten with little consideration to how Service Delivery/Service Management will run, diagnose, recover and ensure the solution meets the required service levels. This is often referred to the IT-IT Gap, where the implementation project does not talk to the service delivery/service management world, and at handover from project to run… there are issues which could have been avoided by total life cycle thinking.

The artITechiture solution architecture method makes explicit reference to each phase in the recommended documentation, the documentation should be considered both a formal document but also a prompt for thinking about all aspects of the systems life-cycle.

artITechitecture Solution Architecture Method March 4, 2009

Posted by Chris Eaton in architecture, architecture method, IT Architecture, methodology, methods.
Tags: , , , , , , , , , , , , , , ,
add a comment

Today I am publishing the artITecture architecture method. This is a complete architectural method to think about and document a solution level architecture. An overview of the artITecture method can be found in this presentation.

All work product descriptions and templates can be downloaded from this page.

This is the first draft, comments are corrections are welcomed, i am certain it is not error free nor that I have managed to consider every aspect of solution architecture – more minds will improve it.

I am particularly interested in contributions to data and infrastructure architecture, i will credit any contribution but it must be given freely and without any copyright implication.

EA and project management January 16, 2009

Posted by Chris Eaton in methodology, methods.
Tags: , , , , , , , , , , ,

i love architecting stuff, my raison d’etre perhaps. Project managers though, they are my antithesis – they are full of difficult questions inhibiting my creative juices, how long will it take? whats the deliverable? what other resources are needed? any risks? what will it cost? ARG!!!! just let me draw my diagrams 🙂

but lets not forget project management altogether, actually applying project management discipline is really important to defining what you want to achieve, what resources are needed to achieve that goal and the plan and execute to make it all happen.

One brilliant tool i will take away from my IBM days is the Project Definition Workshop and the associate deliverable of a Project Definition Report (or project charter) – this sets out right at the start exactly what you are trying to achieve and what it will need to do it, crucially this is held in a workshop format with an independent facilitator with the key stakeholders – this can be a tricky matter to arrange! . The Structure is usually something like this:

  • Goal – one paragraph on the goal of the project i.e. what it is trying to achieve
  • Objectives – things that the project needs to achieve
  • Sponsor and key stakeholders – who are we doing this project for and who needs to be involved
  • Deliverables – what things the project will deliver
  • Tasks – brainstorm all the task needed to achieve the goal
  • Management System / Communications plan
  • Risks/Issues/Assumptions/Dependencies

others agenda items can be added as needed

I have always found this hugely productive and never heard a bad word about the day. It gets everyone on the same page and geared for action

IT Architecture Diagrams II – Recommended Format and Notation August 1, 2008

Posted by Chris Eaton in communications, IT Architecture, methodology, methods, SAP.
Tags: , , , , , ,

**** Click here to download the full example ****

after interest in the last post on architecture diagrams I am writing this description of the architecture diagram notation I have been using for several years.  This format has stood me in good stead for a number of large multi year projects with budgets from $10 to $50 million a year upwards.  In my current role as Chief Architect of the second largest project in IBM Globally we have a project budget in the half billion dollar range, we have hundreds of components and interfaces and the diagramming technique explained below is the one which I have enforced throughout the project, we successfully delivered our targets in 2007 and are on track for this year. It works. It scales. I do not know of any well thought through alternative. Any suggestions for improvement are welcome! I have also provided a download of the example discussed here – Click here to download the example set of Architecture Overview Diagrams – this also includes the additional information I recommend goes with the diagrams.

Example Diagram

I will start off with this relatively simple example (click to enlarge)

This architecture shows an SAP system communicating to a number of other systems. Each rectangular box represents a component and each component is uniquely numbered for ease of reference both when talking about this diagram but also when you create other artifacts you can reference the component using this number. The arrows shows the existence of a data flow between the systems, and again each data flow is uniquely numbered for ease of reference.

Level of Decomposition

Just a note here, when you create Architecture Overview Diagrams you will have to choose the level of decomposition. Look at the SAP box for instance – SAP is made up of many components like the database, SAP GUI, SAP NetWeaver, SAP Portal, etc. For the purpose of this overview diagram is simpler to abstract SAP into one box although really is has many components of interest. I have chosen this level of decomposition for the specific purpose of this diagram. If you abstract components like this you should consider adding another diagram which decomposes these more complex components to a further level of detail down. Have a look in the example presentation with this post. I have a separate diagram just to describe the SAP stack and which SAP components are used. On these kinds of diagrams you should not need to decompose to too fine a level of detail. If you have classes, and operators you are at too low a level for this kind of diagram, that is when you should switch to other diagramming techniques like UML.

Component Types (click to enlarge)

The different colours of the components do have a meaning and each box should be given a meaningful name.

The first box type in dark blue box is a component which is owned and is specifically part of your project scope (i.e. you own the deployment or change to this component), this maybe new or it could be a change to an existing component.

The second box type in grey is a component someone else owns, but no development is required at the other end of the to allow the transfer the data. This is often the case when you develop an interface which fits exactly the format which the other party is expecting without alteration, typically when an integration already exists and this new system is simply replacing a direct copy of what was already there. Small configuration changes might be necessary at the other end to accept the data from your source but this is assumed to be trivial. The implication of no development is that the integration should be relatively straightforward particularly from a project management point of view since the dependency on the other party is not significant.

The third type in light blue is where the other party does need to change and develop something to either send or receive data which was never sent or received before, or an alteration to the integration method. The implication here is the dependency between your system and the other party is significant. Their implementation schedule will need to match your dates for system integration, user testing and production deployment and production cut over.

The last type in light blue with a red surround is a component which sits outside the firewall, all the other component types are assumed to be with your internal network. This is important because the security necessary to talk to external system is often much tighter than communicating with other systems on your internal network.

Arrow Notation (click to enlarge)

First of all the direction of the arrow is important. It show the logical flow of the data.

The solid arrow is a direct flow of data. This is always automated, and alway system to system. The method of exchange is not explicitly described and further explanation will be required. If you look at the example deck the interface mechanism has a textual description and the method of transport. It could be any number of methods like ftp, MQ, JMS, REST, HTTP, SOAP, etc.

The dashed arrow is an indirect flow of data. This will require biomechanical automation (a human) to complete. Typical examples are uploading a spreadsheet or running and exporting a report which is then sent somewhere.

Lastly the red circle is used to show who is the initiating the transaction. The direction of the arrow shows the logical flow, but not who starts the transaction.

So in the first example the data is flowing from System A to B, but System B is the system which initiatives the data flow. This could be calling a service call, or an ODBC connection to System A made by System B to retrieve the data.

The second arrow shows data flow from System A to system B, and it is System A which starts the transaction. A Message (MQ, JMS, etc) would be an example of this, as is a batch interface where System A create the batch interface and sends it to System B.

Other Notation (click to enlarge)

These two boxes are used to uniquely number every single component and interface in the diagram. Diagrams may span several pages, uniqueness should be preserved across an entire architecture.

One improvement I will create to a colleague, Steve McKim, is when a component acts as a passthru, like MQ, or an ftp server label the boxes 6a, 6b, etc. This makes the diagram much easier to understand when the same data is flowing through multiple components.

Diving into the Example Diagram

Lets now take a couple of interfaces from the example diagrams and explain them, the first is generating a message from SAP and passing it to Websphere Message Broker

So you can see we have three components, and 2 interfaces. SAP generates a message and send the message to MQ. MQ is simply a pasthru and automagically send this to Websphere Message Broker. You can see the use of the 6a/6b notation on the interfacing number. The data is unchanged by MQ so it makes sense to show that the data from SAP is being moved to WMB unaltered.All of the arrows are solid so all of this is automated. Since this is a messaging model, SAP initiates the data flow to MQ, and MQ in turn initiates the data push to WMB. for simplicity I have left off what WMB does then. WMB is IBMs heavyweight messaging solution (ESB) so you can safely assume this does allsorts of data transformations, logging, and connections to allsorts of systems via any number of protocols.

The diagram itself is not sufficient to explain everything to the inquiring mind. Why SAP is generating this message is unexplained, how does SAP connect to MQ? SAP does not have native MQ connectivity nor does it generate MQ headers automatically so how is this done? All of this kind of thing needs to be covered in the detail documentation. In IBM and ITIL language this is a Component Model this is somewhat akin to good old internal and external design documents. I would also advocate proving a short explaination with the diagram and I have provided this in my full example.

The second example is a less clean indirect integration.

In this example a spreadsheet is created or updated somehow from SAP. The use of the dashed line indicates this is only partially automated. In this case a user is exporting a report into a spreadsheet possibly onto a server (more than likely their laptop/PC) and then using that spreadsheet as the data source for a Lotus Notes database. They are probably using an Agent in the Lotus Notes database to find and import the data.

Just the same as the first example, the diagram does not explain all the detail, but it does communicate the general data flow and you can make reasonable assumption about what is happening. Further detail is needed to fully explain the flow, what is happening and why. The detail must also cover other considerations such as how the spreadsheet is secured if it contains confidential information.

And Finally…

Remember that these diagrams are a communication method. In any good communication you know your audience and you tailor your communication to them. This notation is very good for communication with other architects and developers at a project level but also at Architecture Review Boards. I have also used these with auditors who often have technical leanings. This format probably isnt what you want to show an executive 🙂

I said it a few times already these diagrams are useful in their own right but you will need further detail documentation to explain more about what is happening and why, particularly to developers. A crucial piece of the notation is the unique numbering format which allows you to tie any given component or interface shown in this diagrams to the detail documentation.