Using Archimate

I have been looking a little more deeply at Archimate 0.1 to see if it will give a useable off the shelf meta model.

The 1st reaction that I have had from a real customer, is that we EA’s may understand it – but not his business managers and executives.

How much time and effort do we expect customer’s staff to put into understanding our EA models?

I guess that it depends, but for the at a most 20 minutes attention span of busy a CxO the answer is that there is not much time and energy available for learning to understand different graphical representations. Indeed it is not just the symbols, but the juxtaposition of them and of the relative diagrams. By which I am thinking in particular of the representation of layers within Archimate.

Coming from a Zachman filled culture the layers are troublesome, and mentally I tip the diagrams on their side! I cannot get my head round the implied hierarchy within the Archimate meta model, after all if a task or activity can be performed by hand, by IT system or by machine where is the hierarchy?

I have been searching for some real life examples of Archimate, and I have not found any. My efforts so far tend to look a little between a process model and a tiered application architecture.

Does any one have any reviews / articles that will shed more light on the use of Archimate?

I think that we could start a thread or discussion on this, if there is sufficient interest. For instance what do we make of the “layering” of Business, Application and Physical dimensions?

May be this has all been discussed at length in the Archimate forum?

Is there a place for peer review of models on the web?

 

Views from 22nd TOGAF Conference

I have just come from the 22nd Open Group EA Conference in London http://www.opengroup.org/london2009-apc/ and survived my 1st presentation to the Open Goup. I was on edge all conference hoping that no one would be presenting similar material to mine. They did not and the Sustainable Enterprise Architecture http://www.opengroup.org/london2009-apc/latham.htm remained my baby.

It has been good to have affirmation that Smart421’s EA http://www.smart421.com/solutions/consultancy/enterprise-architecture.asp proposition matches up to other’s best practices.

This conference was the launch of TOGAF 9, thankfully for my British reserve, not launched with great pomp and ceremony, nor with any Razzmatazz. A little Raz may well have re-enforced the significance of the achievement.

Judging from the mood of the delegates there is confidence in TOGAF 9 and agreement that it is solid as far as it goes.

TOGAF 9 has put on a lot of weight since it was 8, much of it valuable and not at all a middle aged spread into verbosity. Although covering TOGAF 9 at breakneck speed in a couple of presentations on the first full day was not necessarily the best use of conference time. It did show that at least 3 people know TOGAF 9 inside out – I am sure that all of the Open Group members who worked on it are as equally as knowledgeable.

Watch out for Archimate http://www.opengroup.org/archimate/downloads.htm – A meta model to describe Enterprise Architecture, you download the symbols for use in Visio, but to use it properly it needs to be installed in your modelling package. Archimate 2 is due out by the end of the year. I think that it will be a unstoppable force for architecture modelling in years to come.

There were a couple of recurring themes at the conference:-

The hole that is Business Architecture – As Tom Graves http://www.opengroup.org/london2009-apc/graves.htm pointed out IT is less than 10% of expenditure and so by inference we are missing out on 90% of the market for architecture. The hole is being addressed by the Business Architecture working group, but progress is slow and there is much to be done. I want to encourage all knowledgeable practicing Business Architects to dive in a get it sorted.

Enterprise Architects need more soft skills. We are too geeky! This may also explain the lack of progress on the Business Architecture front as the non IT people can not bear to talk to us or as Paul Homan http://www.opengroup.org/london2009-apc/homan.htm put it – they do not understand what we say and anyway we take too long to say it!

Some people were trying to extend the scope of TOGAF, Jason Uppal http://www.opengroup.org/london2009-apc/uppal.htm talking about the 10 year lifecycle of architecture artefacts. Amit Bhagwat explored the relationship between leadership, time span of control and Enterprise Architecture.

On balance there was a lot of talk about theory and not much on the practical application of TOGAF. There is great need to publish practical EA experiences and best practices.
We have contributed to the EA community, thrown in our hat with a model for Sustainable EA. It was interesting that some other presentations were near to our offering of Sustainable Enterprise Architecture – Danny Greefhorst http://www.opengroup.org/london2009-apc/greefhorst.htm talked about Just in Time architecture as part of his Pragmatic Architecture, Paul Homan talked about architecture becoming out of date quickly, if it if not used (Use it or Loose it I suppose) – Martin van den Berg http://www.opengroup.org/london2009-apc/van_den_berg_martin talked of the “Project Start Architecture” the EA Killer Application – But I think that the EA Killer app is the Project Start-up in the our Sustainable EA.

 

Process Modelling and Process Oriented Organisations

I have recently been on a course about Business Process Modelling, which gave me some other perspectives of BPM and how it can be promoted and used by companies.

Prior to the course, I have used a few BPM tools to graphically represent business processes (including IBM Business Process Modeller, Oracle SOA Suite and AquaLogic BPM tools). When using those, I have felt that their use is more related to the automated execution of business processes, through BPEL and service integration capabilities. This seems to be just a technical approach, which isn’t really the solution – although that does depend on how you classify the problem to be solved.

In working with clients, and team members, I have had numerous discussions and explanations on modelling of business processes where there is no technical view involved. It is from this approach that modelling the process can help in understanding, defining and subsequently refining or improving the operations of an enterprise. In process modelling terms, this would consist of creating the Process Architecture for an organisation. From an Enterprise Architecture, this could correspond to the Business Architecture view, where the business is represented as a series of processes operating across defined value chains.

The interesting part of the BPM course I attended was not so much around the approach and methodology described for modelling, but more about the real-world experiences, cases and examples put forward by the course trainer (who does this as a real job, not just as a trainer). Many industry speakers and research analysts are promoting the benefits of process modelling and in structuring companies around process delivery and value chains, rather than in the more common functional silos and hierarchies. The examples discussed on the course seemed to put forward a strong case for this approach (as you would expect), but perhaps with more explanation. My task could now be to summarise and promote those concepts within my own company, as well as that of clients that we work with.

A parallel was frequently drawn with the way in which manufacturing has long been structured and organised around processes, with the production line of Henry Ford being one example. Also, the quality and time controls from Deming et al being another way in which that industry has rationalised and improved over time.

In contrast, the service industry is still mostly structured in functional areas, with a process crossing over many areas and responsibilities from start to finish. That is clearly inefficient. The hand-offs between teams mean that no one person or function is responsible for the process as a whole; each functional area is mostly tasked with ‘doing their job’ and not focused on the end result of the process within which they are working. This is further highlighted by the way in which company budgets are defined. These are nearly always on an area-by-area basis, not on a process-by-process. That can result in functional areas not having any strong interest in delivering value through a complete process, merely in getting their piece of work done in the quickest, easiest or cheapest way. Generally, not the behaviour that an organisation would truly wish for.

A point I would like to repeat from the course is that processes should have objectives or targets and associated measures that cover not only efficiency, but also effectiveness and adaptability. Many measures look just at basic efficiency, which is a waste if the overall process being followed is not actually effective (why optimise a part of a process to the nth degree if that part isn’t even needed in the first place). Analysing and designing processes against such measures can give an objective outcome for any recommendations, and a way to show the gains as a result. Consider also that efficiency gains through optimising process steps may gain percentage improvements, but making larger-scale changes to the overall process may result in many-fold improvements. Figures such as reducing a process from weeks to hours, those are the major gains available to companies if they do things right.

I would think that the one take-away from my views and comments above should be that organisations can definitely be improved through process re-engineering, and that business process modelling is a great approach to achieve this in a visible way. In fact, if you spend time looking at things from a BPM perspective, you would wonder how companies can look for large benefits without such modelling and associated organisation structures.

 

Agile and Enterprise Software Development

Having recently re-read Alistair Cockburn’s book on Agile Software Development, I thought I’d repeat some of the concepts that he describes and try to expand on how those may apply to the development of Enterprise-level software, compared to Application-level software.

There is a very interesting section describing concepts for the design of a methodology for software development. Within this, the choice of a suitable approach is based on a range of criteria, including the following:

• Methodology Size – the number of control elements in the approach
• Ceremony – a level of precision and tolerance applied by the approach; greater ceremony corresponds to tighter controls
• Methodology Weight – the product of size and ceremony, for comparison purposes
• Problem Size – the number of elements in the problem domain and their inherent cross-complexity
• Project Size – the number of people whose efforts need to be coordinated
• System Criticality – the importance of the system, or the level of damage that may by caused by any undetected faults; Alistair uses a scale as follows: loss of comfort, loss of discretionary money, loss of irreplaceable money, loss of life

Other criteria listed in his book are precision, accuracy, relevance, tolerance, visibility, scale and stability. This last one is to determine how likely things are to change, explained with a suitable statement (‘if I were to ask the same questions today and in two weeks, how likely would I be to get the same answers?’)

Those I have included in a bullet list above are perhaps most useful to classify the different types of methodologies, with the others being useful to expand on the detail of any particular approach.

The most commonly-used Agile methodologies, such as XP and Scrum, are inherently lightweight, having minimal control elements and low ceremony, with them being most suited to smaller problems and projects.

Alistair includes an interesting table showing how projects can be characterised by communication load, criticality and priorities. Discussions can then position which type of methodology should, or should not, be used for a project under consideration. Those projects with smaller teams, changing requirements, flexibility in delivery, low risk and small scale are seen at one end of the scale, whilst massive programmes and projects needing strict controls against high risk (financial or life implications) will appear at the upper end of the scale.

In many cases, development of a new piece of standalone application software can benefit from the advantages of an Agile methodology. In this, early visibility of functional software is really useful, allowing changing ideas of the purpose and features of the application to be changed as development progresses. That has to be the true home of Agile software development, backed-up by approaches such as Test-Driven Development to improve the quality of software from ‘day one’.

However, it would seem that for the development of multiple integrated applications in an Enterprise software architecture, this is not going to be the best approach to take. For enterprise-level systems, the requirements are dictated by the business and not just by a set of end users as for an individual application. Up-front work is required to ensure that the overall architecture and requirements are understood, and that planning allows for dependencies between systems to be addressed during the longer software development lifecycle that will be involved. This does not remove the need for good measures of progress and assurances of quality, which can be seen from an Agile approach, but the scale of the project must be borne in mind.

It is for this reason that project management disciplines such as Prince2, and quality control standards such as ISO-9001 have been defined. These are often maligned as being overly heavyweight, but the reaction to use lightweight approaches instead does not often resolve the problems of poor software development and delivery. A lot of failed projects are hampered by understanding of requirements, communication difficulties and false reports of progress. Agile doesn’t fix that on a large scale, although that is essentially what it does address on smaller projects.

Stepping aside from the Agile/non-Agile thoughts, I would tender that for Enterprise-level programmes, the risks of failure are perhaps equal to that of smaller and mid-sized projects, in percentage terms. However, if those odds result in an overrun or under-delivery, then the sheer scale of an enterprise software project will mean that the costs incurred are much higher, the failings more visible, with the lack of delivery being more meaningful to a larger area of the business.

Given these (personal) views, it would seem that there is more risk is using lightweight methodologies for Enterprise-level software development as a whole, whilst still permitting their use within a programme for clearly-scoped or isolated areas of functionality. Would you seriously want to consider an informal approach to developing the software applications that are supposed to drive through large-scale business change in your enterprise? Would you not want to know what you are aiming to deliver before committing to developing chunks of that software?

Another consideration is that, if you wish to move on your whole software architecture to a new platform of integrated components, such as for many SOA initiatives, perhaps the stronger thoughts should go into a phased approach. Doing ‘big bang’ software development and delivery is always an all-or-nothing commitment. Instead, aim to develop and deliver incremental functionality, integrating new with old as you go. This may seem more expensive, due to the extra integration overhead, but this allows better management of costs, reduced risks and also – as for Agile approaches – allows you to use that software from each project phase in live operation if you wish.

To sum up, I feel that software development should indeed be performed in an ‘agile’ approach regardless of scale, but that when looking to delivery Enteprise-level solutions, there is a need for Enterprise-level methodologies and programme management, which is not what gets offered by Agile approaches. I also feel that this is just what Alistair Cockburn presses for in his book; he is an Agile proponent, but he clearly recognises the need for scale to be an input to the choice of approach taken to software delivery.

 

SOA is not just Web Services

This point has been explained in many other places, but still seems to need reiterating for some audiences:

SOA means Service Oriented Architecture

The most important word in that phrase could be ‘Architecture’, not the ‘Services Oriented’ piece – that just applies a modifier for the type of architecture; it does not mean that SOA is just the use of Web Services. Those are a technical interface mechanism and related standards that are indeed prevalent in any SOA environment, but that is only a part of it.

I, and my colleagues, often come up against a technical-biased viewpoint that implementing SOA is just a matter of using Web Services, SOAP, XML and WSDL for application integration. Maybe this comes about from the frequent over-use of the ‘Technical Architect’ job title, but that would be a different discussion with no real ending in sight.

In this context, an architecture implies a framework that is used within an organisation, whether it applies to business, information, application software or technology infrastructure. An architecture should include some form of blueprint and an associated set of principles to be applied to projects or solutions that fit within that architectural domain.

For SOA, a blueprint is an absolute prerequisite for any implementations to go into that environment (actually, for design and even project feasibility). Along with the blueprint should be a set of standards and principles that can be used to ensure the strategic SOA vision can be met. Tactical solutions may deviate from the strategic aims, but only if they can be shown to have strong justification for breaking the defined rules, and even then should have further plans to bring the solution into line for future strategic use.

The process of defining and applying SOA standards is that of governance, which is a form of quality control that applies to a greater level than is commonly seen in technical development projects where design and code reviews tend to take a project-specific view.

For SOA implementations to be successful, services should be designed to support business needs, so that they can be reused by multiple processes and applications, and using common approaches for interface definitions, data models, error handling and security. If these are not defined up front, as part of the architecture, it is highly likely that each set of services introduced into the SOA platform will be inconsistent, requiring additional effort for integration into any composite applications or services. Some of these points, especially that of security, can be very hard to ‘retro-fit’ if a standard is defined after the implementation of a number of service-based solutions. The same problems arise for any other standards that may be defined ‘after the fact’.

Hopefully these comments give a flavour of how SOA requires a broader level of thinking for application and solution design. There is a huge difference between a set of ad-hoc Web Services exposed in an ESB product and that of an architected design using SOA principles for compatible, consistent and reliable service-based developments.

If you are embarking on an SOA implementation, you really do need to form this holistic view of applications, services and business processes, with an architecture governance programme to ensure that the defined principles are applied. Of course, this is where the full ‘Enterprise Architecture’ approach comes in to play, with SOA being a subset of EA.

To those organisations, or more likely, development teams, that are just extending their EJB or COM components with a SOAP interface on an ESB, you should refrain from calling this approach a Service Oriented Architecture, as it most probably is not. It is quite likely to be just another bunch of incoherent application interfaces that will form a birds nest (or can of worms) with connections crossing all manner of boundaries. Well, that is my opinion of what I have seen happen, at least. Oh, one other whinge on common errors, it is ‘Oriented’, not ‘Orientated’. Shoot me if I use the wrong phrase!

SOA isn’t trivial, but if applied properly it can be a much better way of developing solutions within and across and organisation. So don’t be put off by the apparent overhead – doing SOA ‘properly’ is a good idea and should ideally be undertaken as part of a new approach to IT solutions that are using best practices in all possible areas.

I hope you now agree, that SOA is not just about exposing and using Web Services, and that if you are one of those committing the ‘crime’ of misusing or abusing the SOA moniker, please think again and take a step up to the greater view of architected solutions.