We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

Derisking Software Development via Business Modelling

user-pic
Vote 0 Votes
As a consultant I often advise large-scale software development projects that have got themselves into trouble, or fear they are about to.  The root causes are wide ranging, but more often than not, the problems arise from mistakes and/or omissions very early in the development lifecycle.  This is such an old story that one has to wonder - why have people not yet learned that a stitch in time saves nine?

The answer, I believe, is that mainstream approaches to the software development lifecycle still lack mature techniques and accompanying tools in the early stages.  For example, even when a project makes an effort to construct use cases they often turn out to add low value.  This may partly be because use case design has been stripped of entity modeling aspects included in its original formulation, aspects designed by Ivar Jacobson to help ensure the viability of use cases.  However, a deeper reason is that current techniques used early in the development lifecycle are incomplete.  We need more than better use cases - we need more than use cases per se.

Despite dramatic improvements in the last few years in many aspects of software production, such as the emergence of agile practices (including practices associated with iteration such as test-first coding) and higher-level code generation techniques (ranging from programming tools such as "model-driven architecture" to systems for process and rule definition), there have been only minor improvements to the way in which people understand the business drivers that cause software to be constructed in the first place.

For example, consider Rational Unified Process (RUP), which thanks to adoption by IBM is one of the most widely used software development methodologies.  Proponents of RUP claim that it is an almost universal technique, offering support for iterative approaches despite its traditional waterfall origins.  RUP has given rise to an "open" descendant, Open Unified Process (OUP) which is also touted as being adaptable to pretty much any software project.

RUP and OUP place particular emphasis on the early stages of a project, with "Construction" being deferred until the third of four phases, and practitioners being encouraged to use structured disciplines for Business Modeling and Requirements Analysis.  However, dig a little deeper and the picture starts to develop cracks.

In particular, the "Inception" phase of RUP is supposed to include development of a "business model".  What exactly is a business model?  Well, who knows - certainly, there is little in RUP itself (or the accompanying IBM toolset) to explain the term.

The main clue is mention of "business" use cases, as opposed to "system" use cases.  This is a useful distinction, but not a very clear one, and does not go anywhere near far enough.  Where are the business objects of primary value identified, their lifecycles described, their stakeholders defined, and the interactions between these stakeholders captured?  Where are the drivers for high-level system strategy, and the mechanisms for implementation of this strategy?  How are domain security models to be understood and related to user experience models?

TAKE AWAY

Mistakes and omissions made early in a software development project are always the most expensive sort.  Unfortunately, they are also by far the most common sort.

In this new series of blog articles, I will be suggesting ways that you can improve the early stages of the software development lifecycle, by reference to the business modelling techniques of Goal-Oriented Organization Design (GOOD).  GOOD was created as a methodology to assist implementation of Human Interaction Management (HIM) techniques and tools - and a key driver for HIM itself was innovation in requirements analysis (see the HIM Web site for details).

If you are interested to learn how business motivation modelling, process architecture, organizational design, edge stories, user profiles and classic scenarios can help you capture and analyse requirements more effectively, then stay tuned to this blog.

2 Comments

Very helpful post...

Great teaser, please, release the other posts of the new series ASAP :)

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.

Subscribe

 Subscribe in a reader

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT