TOGAF 9 July 14, 2009
Posted by chriseaton in EA, IT Architecture, architecture, architecture method, artitecture, methodology, methods, people.Tags: architecture, enterprise architecture, TOGAF, togaf 9
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
Architecture method template work products / artefacts March 24, 2009
Posted by chriseaton in IT Architecture, architecture, architecture method, artitecture, methodology, methods, total lifecycle thinking.Tags: building IT solutions, architecture, solution architecture, technology, IT Architecture, application architecture, integration architecture, infrastructure architecture, architecture method, solution architecture method, non functional requirements, architecture risk, architecture decisions, systems lifecycle, technical architecture, architecture framework, data architecture, component architecture, nfrs, solution scope, architectural risk, IT Architect, solution design, architecture diagram, architecture methods, software architecture design methods
add a comment
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 chriseaton in IT Architecture, architecture, architecture method, artitecture, methodology, methods, total lifecycle thinking.Tags: architecture, architecture framework, architecture method, architecture methodology, artitecture, IT Architecture, it-it gap, method, service delivery, systems lifecycle, technical architecture, technology, total liifecycle thinking, waterfall
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.
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 chriseaton in IT Architecture, architecture, architecture method, methodology, methods.Tags: architecture, architecture decisions, architecture diagrams, architecture method, architecture methodlogy, architecture overview, architecture risk, change cases, method, non functional requirements, project lifecycle, risk, solution architecture, solution architecture method, technology, waterfall
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.
IT Architecture Diagrams July 17, 2008
Posted by chriseaton in EA, IT Architecture, communications, methodology, methods.Tags: application, architecture, architecture diagrams, architecture overview diagrams, business, EA, IBM EA, integration, qualiware, technology
4 comments
we are coming to the second wave of a major project i am working on which is deploying to over seventy countries. I asked my architecture team to go an find out about the existing architecture of the next set of countries, and some bright spark asked what tool and standards we should use to document this.
For the wave 1 countries I invented an architecture diagramming standard using powerpoint *update* I have written a full detailed explaination of his notation -> here. The major thrust of the architecture work is integration oriented. I’m afraid UML is too detailed, and does not have constructs which show the logical flow – you have to go down to integration diagrams for this. In my mind UML diagrams = the domain of an application architect and possibly an integration architect. It is not the domain of an enterprise architect or even a chief architect.
I know from prior analysis that there isnt a standard for this higher level diagram. In IBM method terms this is called an Architecture Overview Diagram. In essence an Architecture Overview Diagram is a diagram which shows an architecture for a specific audiance and/or purpose. In my case the audience is other architects, with the purpose of talking about all of the significant components and all integration points within our direct control, and integrations with systems we have a dependency on; either to retrieve data from them or send our data to them.
In my model each major component is named on the diagram and uniquely numbered. a component could be something large like SAP, or even an abstraction and a collection of components – again SAP is like this, you have the GUI, the backend, you will probably bucket the database as SAP even though it isnt really SAP (in my case DB2).Or, it could be something very granular like a single service. The level of detail in the diagram is dependant on the audience, but none the less powerpoint is the tool of choice 
IBM itself uses Qualiware to document its own ‘to be’ Enterprise Architecture. I am not keen on this tool personally. Maybe it isnt so much how the tool works perhaps it is the way we use it. I can argue that we mix business flows with integration flows and there is variation in the level of detail and what is shown amongst the various business units who document their as-is architectures.
In summary, there needs to be a standard for architecture charts. There needs to be a standard for enterprise architects, there needs to be a standard for chief architects, there needs to be a view for application/integration/infrastructure/network/data architects. It is astonishing that powerpoint is the major tool of choice. There needs to be referential integrity between these diagrams. Today this is manual, it is not enforced by the tooling.
is someone listening and fixing? 
i can only hope!
