Software designers: Lose your inhibitions, embrace complexity
And mind the gap...between business and IT
Posted in Management, 18th April 2013 10:24 GMT
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
Opinion One of the most persistent reasons quoted for software project failures is the gap between Business and IT – the lack of common understanding, clear communication and shared culture between those that commission solutions and those that design and deliver them. The discipline of Systems Thinking can narrow the gap by envisaging businesses as complex modular systems providing and consuming services – a universal model easily understood by both business experts and IT practitioners.
Few software architects are business domain experts and so they can feel inhibited (or are actively discouraged) from leading business design activities. On the other hand, their business colleagues rarely have the design attitude and technical affinity needed to shape effective solutions, particularly when innovation is called for.
The perennial gap between business and IT does not exist to the same extent with other business specialisms. It has its roots in weak communication, strong differences in culture and attitude, incompatible objectives and often mutual incomprehension. These issues can fade away when business and IT share a common model of the organisation and its functions built on Systems Theory.
For Systems Thinkers, a System is a set of interacting components creating a recognisable and integrated whole. There are two features about Systems in general that are of immediate interest to IT architects: they transform inputs into outputs via processes and they collaborate by providing and consuming services.
Looking at the human body as a System, the lungs use the process of respiration to provide an oxygen-delivery service to the brain, whilst the brain uses the process of cognition to consume input from the eye to create vision. Building on these simple characteristics, Systems also exhibit characteristics such as feedback loops, homeostasis, early and lagging indicators, goal-seeking and boundary shifts. Systems are everywhere, including river systems, political systems, education systems, computer systems, social systems and, of direct interest here, organisational systems.
Business organisations are dynamic combinations of social and technological systems. An organisation is less clearly defined than a human body because different people see organisational boundaries differently and ascribe different purposes to the organisation according to the relationship they have with it. Amazon, for example, might be viewed as an online store, a library of product reviews, an employer, a source of profit, a trading partner, a commercial rival, a target for denial of service attacks, or a source of tax revenue. Each viewpoint brings different parts of Amazon into focus.
Every business organisation is a complex system – a hierarchy of interdependent, collaborative subsystems called Business Capabilities. Capabilities define what a business does rather than how it does it, so typical capability names include Raise Invoices, Deliver Stock, Manage Debt and Report Results. Business Capabilities can be structured hierarchically, with perhaps half a dozen top-level instances decomposed up to seven levels deep until a capability contains exactly one business process. However, they interact with each other and the outside world much more fluidly through a complex network of formal and informal services, many of which will be prime candidates for web services.
At the capability level, many organisations look surprisingly similar in what they do, so much so that the term ‘Business Genome’ has been coined. These similarities seem highly stable across organisations and through time – despite immense technological and social change, after 100 years Ford still buys raw materials, design, build, markets and sells cars and, most of the time, makes money. The real differences are in the way capabilities are implemented, the combinations of people, processes and technologies that transform inputs into outputs. They change markedly from one organisation to another and within an organisation over time. If capabilities map the business genome, their implementation is as unique as a DNA profile.
For software architects, one of the biggest advantages of working with Business Capabilities is that their client organisations begin to look like very much like web-service-enabled software applications. Design patterns for service-orientation, encapsulation, customisation and reuse become highly relevant and useful in a business context. Yet Business Capabilities are readily understood by business colleagues and so provide a shared means of communication that is consistent across a business, its processes and its technologies.
CIOs and CTOs identify the alignment of business and IT as a chronic issue. Business Capability Mapping and Systems Thinking offer real hope of a step-change in finally getting business and IT people talking the same language for the benefit of all ®.
Mike Lloyd is managing consultant at Stuctia. He has designed and delivered numerous major software solutions for the likes of the Royal Air Force, many financial services providers and a Formula 1 team. He now advises a number of blue chip organisations on their strategic change programmes. You can see him present at the "Iasa UK Architect Summit - Enabling Disruptive Innovation" on the 25th and 26th of April 2013 in London. Click here to find out more.
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
COMMENTS
Highly Rated
Capitalization Bingo
I really don't think that describing methods and elements of software design using Randomly Capitalized words is really an answer to anything, neither is the massive abuse of the (supposedly metaphorical) noun 'architect' - don't even get started on its increasing use as a verb. Rehashing old ideas of viewing businesses using analogies to evolved structures, such as organisms, is also somewhat trite and un-helpful.
...and "Systems Thinkers" ? Oh do fuck off..
*Protracted Yawn*
I mean come on, you haven't even got a decent buzzword.
Yet another round of conceptual designing that still doesn't address the problem that the 'business' side is never going to put aside the time to explain what it actually does in terms of processes (at least in the high-finance areas that can afford bespoke software) to anyone - as in many cases it would expose all the gaping illogical holes in what it does.
It may come as a surprise that there isn't actually a shortage of developers or 'software architects' who would genuinely like to understand the need behind the project they've been given. What there is is a shortage of business managers willing to explain/admit/understand* [*del. as app.] in any detail what it is they actually do.
Why business hate architects: architects block bullshit
I think the reason many businesses don't properly use architects is that architects have a nasty habit of blocking bullshit (or at least calling enough attention to it).
Some upper level PHB will say something like:
"I read in an execuporn magazine[1] that we should gather as much information as we can on people visiting our site as we can: name, DOB, address, sex, etc. My golf buddies and I talked about it at the 19th hole and I think we can make lots of money. Make It So - CHOP CHOP!"
The architect, upon doing any analysis, will come back:
"OK, here's the requirements you laid out. Notice that since our web site targets children, most of what you want to do is illegal. Also, you never specified how we would actually use that data to make money."
BOOM! There goes PHB's lovely bullshit fantasy of making lots of money off some ill-conceived plan.
Or:
PHB: "Here's this wonderful new product I want to have shipping in 6 months. Make It So - CHOP CHOP!"
Architect: "Here's the analysis. Here's all the risk factors. Here's the research cost to mitigate them. Here's the staffing needed to do that. Here's the time. Assuming we CAN mitigate all the risks, here is the staffing to produce that product, and here's the needed staffing. Note that it exceeds our current staffing by a factor of 5."
BOOM! Again, PHB is inconvenienced by facts.
So when it comes time to "right-size", who do you think the PHB will be looking to axe first?
There are tools.
It starts with the architect getting off his arse and speaking to people. Across the business, and up and down the management chain. Assuming you know what the end game is (SMART goal/objective), you can start on scope. And that's the difficult part done.
The problem as I encounter it is that architects withdraw into a technical bubble, rather than working on their consulting skills (applies as much in-house as to vendors).
Your architect needs the social skill and credibility you speak of. That means navigating a cultural and political minefield, managing stakeholders, risk[1], and solving business problems.
[1] Risk is one of my favourite interview subjects. Identifying risk is but the first step. And it doesn't stop with mitigation. The most common downfall of managing IT risk (based on over 20 years in IT) is that when stuff goes wrong (something always does), is that there's a mitigation plan which might, if done right, reduce probability, but the contingency is always left out. And that's what you need when the risk becomes an issue.
Re: It starts with the architect getting off his arse and speaking to people.
Right there you're assuming an advantage most software teams don't have - that someone with a vague understanding of software is involved early on in drawing up the task, rather than having the requirement dictated by someone who doesn't even understand what they're asking for, never mind how they'll recognise it when it's ready.
Just look at all the jobs on offer over there ->. £20k for building web and .NET and C# front-ends for the back-end DB spaghetti that businesses accrue over the decades. Student rates. No-one writing the cheques is even slightly interested in hiring someone who might actually take a look under the rug, or ask questions, so how is this 'better product' ever going to happen?
The new Office Garage series:
