Book Review: Lost in Translation

41AC-rjnCeLLost In Translation: A handbook for information systems in the 21st century
Nigel Green, Carl Bate
Evolved Technologist Press; First edition 2008
ISBN-13: 978-0978921842
172 pages paperback

Normally, I do not write reviews for bad books. In this particular case, I will because for some strange reason even after 5 years in the wild it still has only five-star reviews on Read more…


Importance of System Ownership

We (architects) keep telling people that every system in the enterprise has to have an owner. Yet, we rarely make the case strong enough, and, occasionally, end up with solutions that do not work. Alas, the concept of system ownership is somewhat obscure and not easily graspable by not only laymen, but fellow professionals as well. This is an attempt to write a simplest possible explanation of the matter.

Software is meaningless in itself. That may sound far-fetched, but you have to agree that figures on a computer screen mean something to a human operator not because of some inherent property of a software system. What software system can do is to store, retrieve and manipulate arbitrary symbols — it’s a symbolic engine (or syntactic device if you know what I mean). It just ‘happens’ that the symbols reflect the reality in a way that is meaningful to someone, in particular, to the user.

Read more…

The Nature of Gartner Hype Cycles

I’m sure you heard of Winston W. Royce, prominent scholar of software engineering , the author of influential article on managing development of large software systems. The article is widely recognized as the ‘bible’ for the waterfall model for software development, despite the fact that it doesn’t mention ‘waterfall’ at all, nor does it describe anything close to what is known as the waterfall model. Unfortunately, this is exactly the impression first two pages of the article make, and, arguably, most readers couldn’t make it past the second page.

However, there is another example of the same problem which, perhaps, has even wider impact on the industry. I’m talking about the notion of hype cycle conceived by¬†Jackie Fenn and productised by Gartner.

On the surface it looks deceivingly simple. Firstly, analysts asses the media visibility of a particular technology. Then, the level of visibility is mapped onto intuitively simple model of hype curve — like this one. As a result, the ‘position’ of the technology on the horizontal axis tell you how mature the technology is. The only thing left, allegedly, depending on your (or your executive’s) appetite for risk, is to decide whether you’re going to adopt the technology, or wait for others to explore the uncharted waters first. At least this is what Gartner’s introduction into Hype Cycle research methodology tells us.

The funny thing is that most people who take the position of a particular technology on the Hype cycle into account when making investment decisions never read past that description. Not surprising, because for 29-pages in-depth overview of the research methodology Gartner charges US$995 — enough to suppress occasional spark of curiosity.

The following is a compilation of my own observations with regard to making sense of Gartner’s hype cycles, backed by the fact that I did read the paper on the methodology. Hope you’ll find it useful.

First and foremost, the ‘hype curve’ phenomenon that could be measured and plotted as a chart does not exist as such. By that I mean that one cannot find the evidence of the fact that a technology has entered, say, the Trough of Disillusionment phase merely by checking the volume of publications or similar accessible measure. It is always an analyst’s call. Hence, it is not an input into an analysis, it’s an output that goes alongside with the narrative.

Secondly, Gartner itself is inconsistent in applying the research method, especially around the presentation aspect. In one publication horizontal axis could be labelled as ‘time’ and in another publication is becomes ‘maturity’, which is clearly not the same thing. Again, it’s not an input, it’s part of the message.

Thirdly, the model implies that the technology is well defined and consistent construct which has a lifecycle. Whilst it could be true in certain cases, namely, when the technology is closely related to a particular market niche serviced by group of vendors, it’s not something to take for granted in general. Consider ‘NoSQL’ theme, or more recent ‘Big Data’ one. This is where it becomes fuzzy and dangerous.

Finally, Hype cycle model is not falsifiable in Popper’s sense. By that I mean one cannot draw any ‘interesting’ predictions that could be proven right or wrong. In particular, no one can reliably predict how long would it take a particular technology to mature by merely looking at some publication figures. Where the model works well is in explaining the current situation and recent events, which, again, means it is a plot device, not an input.

All those observations are fairly easy to explain if we consider the underpinnings of the phenomenon of hype cycle. As Jackie Fenn explains in the methodology paper, it is, in fact, a combination of two more or less independent tendencies. Firstly, any emerging technology gets good initial media coverage, which tends to trail off at the point when it stops being noteworthy for majority of the audience. Secondly, any widely used ‘commoditized’ technology creates an ecosystem around itself consisting of people using it, selling it, teaching it, and looking for talent or advice. Combining these two trends together with some normalization one can demonstrate the emergence of the curve similar to one normally depicted on Hype cycle diagrams (by the way, demonstrating it is a very interesting exercise in system dynamics).

And this is where, I guess, main takeaway point lies. It is counter-intuitive and, hence, useful. By the nature of the underlying trends, technology evolution doesn’t stop as the lowest point of the Hype cycle. In fact, it is the point where it matures as fast as never before. One looking for investment opportunities into technologies, should closely look at the ‘saddle’ of the chart for some fresh ideas.

Can an architecture emerge?

I had a discussion the other day about whether a sensible architecture can emerge provided that some sort of iterative development is taking place, allowing for rework to certain extent, but without any up front design going beyond the scope of current iteration. As it usually stands, all the best arguments come when you’re trying to fall asleep the following night, so this post is an a posteriori attempt to present a consolidated opinion on the matter.

Firstly, coming to terms. Architecture, as prominent international standard stipulates, is a property of a system in contract to architecture description, which is a separate work product. Hence, any system — as opposed to simply a random collection of items — has an architecture, regardless of the way it came into existence. This effectively dissolves the question, but doesn’t give any practical insight. To keep the discussion relevant, I’m reframing the question as follows: can an iterative development process without any up front design going beyond the scope of current iteration produce a system with good architecture?

Read more…

The Case for Capability-Driven Solutions

I’ve been reading a new 2011 edition of classic Systems Engineering textbook by Kossiakoff, et al., and it occurred to me that there is a significant difference between how enterprises normally acquire IT solutions and how Systems Engineering prescribes it to happen, which I haven’t previously paid attention to, and this is the source of many troubles.

The usual practice in enterprises is that IT projects start with an appreciation of a problem and an intention to uncover business requirements. The first project assignment involves an analyst and, potentially, an architect who are appointed to find out what are the problems of the business in a particular area and to put together a project brief. The latter is supposed to provide enough justification for an additional round of funding that would enable a certain activities to initiate the project, e.g. doing systems analysis, designing high-level architecture, putting together a business case — all your normal PRINCE2-mandated work items.

The principal consequence of this approach is that those initiatives become problem-driven. In itself it’s not a bad thing. Ultimately the value of IT is to support business operations and, obviously, if there is a problem in business operations that could be solved by IT a project will be commenced for sure. Of course, provided that there are budget and resources available. The bad thing is that the problem-driven stance of IT causes few adverse enterprise-wide effects .

Read more…

Cardinal Sins of Engineer: Ignoring the People

A particular idea I really liked to write a post about a while ago is to summarize errors that IT architects (including myself) make from time to time. The underlying motivation was based on the hunch that there’s a finite and quite limited list of actual root causes, and by having the causes listed and reflected would help me and anyone else avoid this kind of mistakes in the future. As a result I’ve started to put together a let of ‘capital sins’ of an engineer.

And this is where problems started. As we all know there supposed to be seven deadly sins, but despite my efforts I could only come up with six at most, and even then I wasn’t actually convinced about whether the last two were independent or just special cases of earlier ones.

So, I decided to take a step back and put everything into as few broad categories as possible in order to make any subsequent refinement and adjustments easier. This post is about the first category, first and foremost cardinal sin of an IT architect: Ignoring the People.

Read more…

Book Review: Systems Concepts in Action

Systems Concepts in Action: A Practitioner’s Toolkit
Bob Williams, Richard Hummelbrunner
Stanford University Press 2010
ISBN-13: 978-0804770637
296 pages

Systems Science is raging in attempt to explain and harness systemic phenomena that would work regardless of the system’s nature. This book aims to present a variety of practical, tested, wide-ranging and multidisciplinary methods available to a practitioner who is in need to make sense of and change systems, whether it is a particularly tricky situation, a project, an enterprise, a social network or even an industry.

Read more…