jump to navigation

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: , , , , , , , , , , ,
3 comments

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

my hearing is going? November 24, 2008

Posted by Chris Eaton in Uncategorized.
Tags: , , ,
add a comment

i dont usually do personal posts, but two oddities in one day forced my hand, although I cannot decide if it was clever phraseology or wishful mishearing…

on an advert reading a phone number out the reader got to 411 and instead of say ‘four, double one,’ said ‘four double fun’

and on the train some guys drinking a few tinnies posed the question ‘is there a pint of no return?’

Game Theory and IT Strategy November 20, 2008

Posted by Chris Eaton in EA, methodology.
Tags: , , , , , , , , , , , , , , , , , , , ,
1 comment so far

I am currently reading the selfish gene by Richard Dawkins, it is a fascinating book not least because the thesis draws on research which combines (what i believe to be) previously unconnected analysis techniques like Game Theory with genetics with animal behaviors (ethology).

This really got me thinking how techniques from other fields of science could be used in Information Technology (if you consider IT science, perhaps it is an art!) Coincidentally I work in the field of IT strategy and at university my Computer Science dissertation on the card game of Bridge used aspects of Game Theory to formulate the best strategy for any given hand or game, although I can only consider myself, at best, a ham amateur in all of these fields.  (I am curious now why i never quite put IT strategy and Game Theory together before now, and a quick google search suggests that whilst game theory has ben applied to other areas of IT there it has yet to be applied to IT Strategy which is rather surprising)

Wikipedia defines Game Theory as follows ‘Game Theory attempts to mathematically capture behavior in strategic situations, in which an individual’s success in making choices depends on the choices of others.’

actually I would adjust this to be ‘Game Theory attempts to mathematically capture the outcomes of behaviour in strategic situations…’ I maybe saying the same thing as the Wikipedia definition but i want to stress that the analysis of outcomes are key in game theory not part of trailing secondary sentence, albeit that the analysis can only be as good as the model you construct.

My question is could a model be built which would could analyse different IT strategies and allow decisions to be made based on the outcomes (presumably the best outcome) – crucially Game Theory analyses the strategy in the context of other competitors and their strategies, the implication being that an strategy is only as good as the strategies of your competitors – if their strategy is better you are going to lose.

I would suggest that IT strategy and investment planning today probably does consider alternate investments and their likely outcomes but only in the context of the organisation itself and not the competitors. I suspect the vast majority of organisations call this analysis a business case . The measure of a business case is almost always a definite dollar return like headcount reduction which is convieniently provides a very definite and measurable outcome. However this excludes strategies which may bring a competitive advantage based on probabilistic outcomes (which I will call a ‘soft benefit’ which are outcomes like a probable increase to sales).

My experience is that any CFO is very unlikely to fund a project based on a soft benefit return not because CFOs are closed minded, but because the claimed return of soft benefits has wholly inadequate research and justification. The CFO is making a judgment call on the probability of an investment making the claimed return. In my experience soft benefits are frequently (always?) overstated, they are often highly speculative based on gut feel, they rarely (perhaps never) have good analysis and research behind them which backs up their claims. By using game theory the accuracy of the benefits and probability of a particular strategy success can be improved, perhaps to an extent where a CFO might take a chance.

so in conclusion, and a very unsatisfactory conclusion at that, i would like to build, or see a model built which could do this analysis. Perhaps on the train tomorrow i can think more on this and the likely parameters. At the weekend maybe i will search my loft for some of my forgotten economic textbooks.

speak in a language others can understand October 8, 2008

Posted by Chris Eaton in communications, EA, people.
Tags: , , , ,
add a comment

I came across a very good article here named EA Demystified. One of the salient observations is the use of language which is only comprehensible to people familiar with EA. Actually, I have stopped introducing myself as an Enterprise Architect because I receive such blank looks, and even if someone has an appreciation of the term ‘enterprise architect’ they ask for a clarification since it can mean so many things.

TOGAF in particular needs a makeover in this space using terms like ‘Enterprise Continuum’ which fails completely to communicate what it is, and presents a complete barrier of understanding to any but those familar with TOGAF. This is a defnite communication fail.

Below is another example i came across today is in wikipedia in the entry for Enterprise Architecture – here . ‘One method, described in the popular TOGAF architectural framework, is to develop an Architectural Vision, which is a description of the business that represents a “target” or “future state” goal. ‘

Well, in my opinion someone completely misunderstood the use of ‘Architectural Vision’ in TOGAF which is about selling EA and obtaining Buy In from stakeholders to start and continue to support EA. In TOGAF Target Architecture is about future state architectures, not Architectural Vision but im not here to criticise the wikipedia entry, my critism is that TOGAF once again uses language which is unclear, open to interreptation by EA practitioners let alone the uninitated in EA.

so some very simple advice, use simple language in communications.

for the enquiring mind, i introduce myself as ‘working in IT Strategy’ , which i think is a reasonably comprehensible to the average joe and certainly recieves a much more warm reception than an Enterprise Architect. I hope one day I can say i am from the ‘Business and IT Strategy but my team is still seen largely in the technology space – for now..!

Whats the value of TOGAF certification? August 27, 2008

Posted by Chris Eaton in EA, mentoring.
Tags: , , , , , , , , , , , , , , ,
152 comments

A mentee wrote to me with the following questions on whether TOGAF certification is worthwhile and where it might lead, here is my take on what he asked about…

  • How do I become TOGAF certified?
  • What kind of insight you will be able to give in terms of the Return on investment of TOGAF certification?
  • If I take the TOGAF exam right away what kind of opportunities should I look for and who are the potential employers?
  • At this stage what would my typical work profile be if I get a EA job?

How do I become TOGAF certified?

There are two routes to TOGAF certification, the first is simply to sit the exam, the second is to attend a TOGAF certified course which takes 4 or 5 days to go through all of the TOGAF material and results in certification and there is no exam.  I have TOGAF certification through the course. I have read that the exam is relatively straightforward but like all exams preparation is key and a decent knowledge of TOGAF is needed Take a look at the Open Group website for TOGAF Certification

What kind of insight you will be able to give in terms of the Return on investment of TOGAF certification?

For me TOGAF certification has been a great investment. I achieved certification by taking the certification approved course and I should add that the course was paid for by IBM. My own situation is about to change and I am about to leave IBM to work for another multinational based here in the United Kingdom. My new employer has checked my TOGAF certification credentials and I believe this gives an indication that they considered this very important. I also want to add that holding TOGAF certification alone is not likely to convince a potential employer that you can work as an Enterprise Architect. Some work experience in the Enterprise Architecture area is likely to be very desireable. This leads into the question how do I find my first EA role?  That is a great question, one not easily answered and perhaps the subject for a future post 🙂


If I take the TOGAF exam right away what kind of opportunities should I look for and who are the potential employers?

EA remains a relatively specialised field, it is likely that most work will be with larger organisations. In my mind Enterprise Architecture is very much about the optimisation of available IT spend to ensure that available investment money is directed to strategic IT systems rather than wasting money investing in short term or legacy systems. Larger organisations are more likely to have problems with these aspects of investment since often they have disparate IT offerings and duplicate systems resulting from a lack of coordination across companies and countries or because they are making acquisitions who have made their own IT which may or may not match the IT of the buyer.
In terms of potential employers there is tremendous interest in EA at the moment in all sorts of organisations. You can either look to work directly for organisations like banks, manufacturers, retailer etc, or look for work in an Enterprise Architecture consultancy. If you wanted to move into EA consultancy then most of the large consultancies have EA practices. I know IBM, HP, Cap Gemini all have EA practices and are recruiting at the moment and I am sure there are other smaller or specialised companies in the EA space.

At this stage what would my typical work profile be if I get a EA job?
This is a really good question. EA is very broad in its scope, and the EA means different things to different people and organisations. The major interest area tends to be creating strategic ‘to-be’ architectures which often (always?) includes looking at the as-is architecture and what exists today and making decisions on what the strategic architecture should look like in future. A huge part of EA in general is communicating and selling your ideas and vision.  The main area that I work in is the evaluation of IT offerings against the business processes and business requirements and selecting the strategic applications and middleware to meet those requirements. I would call this Enterprise Application Architect. In my mind there are four technology specialties which coincidently match how TOGAF splits EA into Business, Applications, Infrastructure and Data. In no particular order they are:

  • Enterprise Applications Architect, as described above this looks mainly at creating strategic architectures focussed on software, both applications and integrations
  • Enterprise Infrastructure Architect looking at hardware, networks, operating systems, server locations and capacity etc, and within this further specialization would be Security and Networking.
  • Enterprise Business Architects, looking specifically at business processes design and optimization
  • Enterprise Data Architects looking at data requirements, placement, maintenance and reporting

Deploying or improving governance processes like architecture review boards, IT spend planning and change management is also likely to be part of the work.

So in summary you could be doing anything in the EA space 🙂

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

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

**** 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.

looking for mentees July 18, 2008

Posted by Chris Eaton in communications, IT Architecture, mentoring, people, Uncategorized.
Tags: , , , , , , , , , , , , , ,
1 comment so far

I am looking to mentor people in IT architecture. Part of the Open Group IT Architect Certification (ITAC) requirements is ‘giveback’ to the profession and mentoring is one of the most important. I have experience as an application, integration and enterprise architect with particular technology experience in SOA and most IBM software

Mentoring is not just about technology, it is also about careers, coaching and soft skills…

I also have quite a few certifications which i can help with too, including TOGAF, ITAC, Sun Enterprise Architect and Project Management Professional

I am also a dab hand at reworking CVs and Resumes…

If you are interested in discussing mentoring please contact me at gruffoot@gmail.com