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…

Advertisements

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

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

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

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.