Monthly Archives: February 2010

Enterprise architecture frameworks – TOGAF and MODAF

I’ve been looking at Enterprise Architecture frameworks such as TOGAF and MODAF as people have suggested that some of the work we have done on responsibility modeling relates to these. I can see a tenuous link but that’s not what this post is about.

EA frameworks strike me as the brontosauri of the methods world. They have a view that the world can be architected starting with the business and then (somehow) defining and enterprise architecture that tries to tie together all of the systems in that business. It’s all about top-down reductionism and nowhere is the inherent messiness and unpredictability of the world taken into account. They assume that you can set up stable business goals and use these as a driver for defining your enterprise and hence defining the set of systems that you need.

Well I have worked in several enterprises and have, like almost everyone else in these enterprises, have considered the stated business goals as a joke. Business goals are statements that may make senior managers feel good when presenting the business but they are so far removed from organizational reality that they don’t strike me as a good basis for defining a long term vision for systems in an enterprise. Problems with business goals are:

The personal goals of the people in the organization are not necessarily aligned with the business goals. People are driven by personal motivations (goals is too strong a word) and mostly couldn’t care less about the business goals. Why should they – in many large organizations, senior management are concerned with the shareholders rather than the people in the organization. The difference in rewards between the highest and lowest salaries in many enterprises is obscene and people are treated as disposable commodities.  At best, the people in an organization will ignore the business goals; at worst, they will actively oppose changes driven by these goals as they see them as undermining their ability to do their job.

Changes in the world are so significant that they overwhelm business intentions. Business goals can only be established on the assumption that there is some degree of stability in the world so that a plan derived from the goals can be executed. However, all of the evidence that we have suggests that no such stability exists. Things happen – collapsing banks, lack of credit, changes of government policy, new disruptive technologies, natural disasters, etc. that  mean plans have to be torn up and rethought.  A top-down, goal-driven view of the world is simply untenable.

This means, IMHO, that the basic premise of these EA frameworks is fundamentally flawed.

And, then we come to the complexity;  TOGAF is described in an 800-page book  and suggests literally tens of different views of the enterprise architecture that should be produced. No mention of the costs and difficulties of keeping these up to date or attempting to demonstrate/maintain consistency. Clearly the costs of introducing these EA frameworks are huge – and how can the benefits be assessed?

I used the term ‘brontosauri’ deliberately to describe these methods. Huge and the last of a line that is doomed. I have some doubts about agile methods in general but, when it comes to modeling, I’m in complete agreement. Just Barely Good Enough is definitely the right approach – agile modeling is immature but definitely the first of the mammals that will take over from the dinosaurs.

Leave a comment

Filed under LSCITS

The history of version control

N.B. Ruparelia, SEN, 35 (1), January 2010

A brief history of software version control from the 1970s to the present day. The article presents a general overview of version control than briefly summarizes a number of different version control systems. Most of the focus is on open source systems and the author doesn’t mention broad CM tools, such as Clearcase. I don’t think he gives enough credit to SCCS as the pioneering system in this area. In general, this is a good starting point for further reading (and googling) on version control.

http:doi.acm.org/10.1145/1668862.1668876

Leave a comment

Filed under SE9-Reading

What should we teach in CS courses

I read an interesting article today in the CACM by Bjarne Stroustrop (inventor of C++) who was bemoaning the fact that university CS courses are not aligned with industry needs and proposing that the problem should be addressed by making the first CS degree a Masters rather than a Batchelor’s degree.  He concludes that the answer is a ‘body of knowledge’ (he calls this a ‘core’+application areas) and licensing of software professionals.

While I agree with his description of the problem, I think this whole body of knowledge stuff is simplistic. What on earth is core computer science – when I started teaching CS, it was inconceivable to have a CS course without compiler theory and development. Now, hardly any courses have such things – and, in truth, it doesn’t matter that much.  Who really cares about Turing machines?  Some people who work in the software industry really need discrete maths but if you are developing simulation systems then maybe knowing about differential equations is more important.

The fact is, software is so diverse and different types of software have such different knowledge requirements (e.g. compare computer game development and database programming) that we simply cannot cover everything in a course be it a Batchelor’s or a Master’s course.

The licensing route is a slippery slope to ossification with licenses controlled by a small group of greybeards who are not in touch with modern developments (we see this in the UK in BCS accreditation of courses). It’s really not a good idea.

And the other thing that we in universities must always remember – industry is not our customer – they pay very little towards the university system. Our paying customers are students and if we offer dull and irrelevant courses, they will vote with their feet and go elsewhere. I reckon that was part of the problem for the decline in CS enrolements (some universities have faced up to this, others continue to delude themselves that it was all to do with the dot-com crash). Courses are getting better and I think that, in the UK at least, they are slowly being updated to reflect 21st century needs.

1 Comment

Filed under CS education

Toyota braking problem

It’s fairly clear that the Toyota Prius braking system problems are software related and to do with the interaction between the ABS and the regenerative system that recovers energy from braking. Whether this was a software fault or a specification fault isn’t clear but it reveals that when we add complexity to a system, we are likely to run into problems. Toyota are being rightly criticised for this (and, for sure, they have handled the problem badly) but they are being innovative and an inevitable part of the price of innovation is that problems will occur.

We need to remember this if and when we are tempted to be judgemental about software faults.

2 Comments

Filed under Uncategorized

Software Engineering 9th edition

Well, the 9th edition of my software engineering book has gone to the printer and will be available in bookstores in April. I’m done with proof reading and am now working on the book web site and supplementary material. Like everyone else, I’m not great at keeping web sites up to date so I thought I’d create this blog to record thoughts on my work-related reading (some of which is relevant to the book), software and systems engineering topics  and other engineering related stuff.

4 Comments

Filed under Uncategorized