Software designers: Lose your inhibitions, embrace complexity

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 …

[Spearchucker Jones]

You could do all that...

...or you could, as an architect, assume some initiative and -

1. Start by creating and sharing a common vocabulary and approach to a problem.

2. If your approach is outside the box, don't forget to understand the box. Politics and culture, you know?

3. Create an objective[1] for your project that's realistic and measurable.

4. Design your solution[2].

[1] Replacing an ageing system with a new one is not an objective. Improving performance by 10% is an objective.

[2] Worth remembering that your first idea is never the best idea. All it has going for it is being your first idea. When considering other options don't create straw men to support your first idea.

[Anonymous Coward]

Re: You could do all that...

KISS rule, keep it simple and use insightful humour.... For instance do an image web search for this :-

"tree swing cartoon"

A.K.A

"What the customer (really) wanted...."

[Anonymous Coward]

*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.

[Don Jefe]

Re: *Protracted Yawn*

Gaping illogical holes... That's the problem right there. Many business problems aren't logical & can't be explained easily without a solid understanding of both the business itself and business in general. For some reason many executives don't appreciate that most IT people are capable of understanding business but at the same time IT people don't want to embrace the 'buzzword' culture of business (everything is illogical or stupid)

Both sides generally have poor attitudes when it comes to communication and both sides find frustration with the jargon and acronyms. At the end of the day it takes people on both sides to communicate in in terms that both sides understand and with attitudes that don't demean others. That was originally supposed to be the role of the CIO but too many companies just promote (or hire) someone who is too grounded in one world or the other. The best CIO's I know aren't great coders or architects and they aren't the greatest business minds either: They are terrific interpreters and diplomats who can speak both 'languages' and still look good in a suit or in a T-shirt & boots.

[Brewster's Angle Grinder]

You lost me at "river system"...

...presumably a river consumes BS to produce borderline potable water by the process of dilution. In which case, it is a perfect metaphor.

Seriously, why does the process matter? As engineers we are taught to model system as black boxes with inputs and outputs. You don't need to understand the box unless you are tasked building it. And you don't need to "consume" anything, except truck loads of BS. Which brings me back to the river.

[Anonymous Coward]

"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"

I thought that's what analysts were for, before they seemed to dissapear as an old fashioned concept (at least where I work) . We used to have analysts who worked in the business and analysts who worked in IT, they'd get together and hash all this out, and it seemed to work fine. That step seems to have fallen out of the development process in recent times though as unnecessary.

[Anonymous Coward]

I think the biggest problems faced by architects is that the problems they are solving often cross functional and even conceptual boundaries within the business, and the business's supply chain, without them even realising it. You think you understand the problem, you can draw it, solve it on paper and implement it and all too often a problem emerges from the left field. Then the project costs start to move upwards.

Merely understanding the flow of data and process through a business is never really good enough, and reveals the difference between someone who is merely competent and someone who is great (I'm neither BTW but my job employs a subset of what architects and analysts do). There are no tools or techniques to help at this level and success ultimately boils down to personality.

[Spearchucker Jones]

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.

[Anonymous Coward]

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?

[Faye B]

Re: social skill and credibility

An architect can have all the social skills and credibility of Johnny Depp but it won't mean a thing if the managers won't even give you the time of day, let alone condescend to actually talk to you about the project. Oh no, their time is much too valuable to discuss what the project is actually meant to do and the idea of having to explain the details to the "grease monkey doing the boring stuff" would be beyond the pale. If this sounds cynical, ask yourself why IT projects always overrun and go vastly overbudget. It's not down to slow lazy developers, that's for sure, it's more often because management refuse to admit that it will cost that much and take that long.

[Spearchucker Jones]

Re: social skill and credibility

There are many things you can do. Start by talking to the manager informally about the impact of his/her non-committal (if you can't quantify the impact, quantify it). If that fails, try email, which offers a paper trail. If that fails, informally sound out other stakeholders to see if there's a reason you're missing. If that fails, raise the manager's lack of commitment as a risk. If that fails, make it an issue, stop the project, and let all stakeholders know why, providing a log of events.

Try harder. Saying other people are stopping you is a cop-out.

[Faye B]

Re: social skill and credibility

.... And if that fails go get another job.

I think that list shows just how hard it is to get managers to actually respond. By the time you have jumped through all those hoops the project will be over and your name will be mud all around the company for being a pain in the a**e. Good luck with being chosen to be architect for the next project after that rigmarole.

You can't use process to make people cooperate and help you, it just alienates you. I know, I've tried.

[Roland6]

Re: There are tools.

>Risk is one of my favourite interview subjects.

I find the subject that tends to dominate many of my interviews is 'context' (although some may call this 'terms of reference' and/or scope) followed by conceptual design as these shape the entire solution approach and delivery project. For example with one client I spend the best part of two months going round in circles between the various business units and stakeholders getting them to agree the contents of the Prince2 PID, having done this we were able to knock together a board case for multi-million pound project in a little over a week and get it approved.

So totally agree "It starts with the architect getting off his arse and speaking to people. Across the business, and up and down the management chain." which for many from a pure or deep technical IT background does not come naturally or easily.

[Anonymous Coward]

re: biggest problems faced by architects...

It's that the functions cross boundaries without ANYONE properly realising it. It's the informal ways that data can flow; how people can bend when they recognise another's work is, at that moment, more critical than their own, that can give a business (particularly a small one) an edge. Yet none of that is captured in procedures; it's barely recognised more than one or two layers up the hierarchy. Yet without it, you fail.

But when it comes to putting those things in software, if the manager can't quantify it then what hope has a programmer got?

It's not enough to say, let's sit around a table and work out the differences in the lingo. If I'm a developer and I want to turn my software skills into a business, I need to learn business skills so I can play that game. So why should those with business skills who want to turn them into software only be expected to meet half-way? One of the things software development does is teach you to break everything down to the simplest rules and stick by them, no exceptions. If you want a special consideration, make a rule of it and add that in too. No exceptions. If a business process can't or won't play by those rules, it's never going to work as software. Half measures don't cut it.

[Brewster's Angle Grinder]

Re: re: biggest problems faced by architects... @Joefish

This...

If a business process can't or won't play by those rules, it's never going to work as software.

...should be framed.

People still think computers are "logical". (And by "logical" they mean something that can use Aristotlean logic, not something that incorporates a smattering of boolean logic.)

I have to explain to them that computers are "algorithmic": they just manipulate numbers by following a laundry list of rules. A line of code is just a box in a flow chart (effectively).

[Anonymous Coward]

Taxing

"Amazon... or a source of tax revenue" Hmmmm.... In the UK?

[Charlie Clark]

Nice work if you can get it

But I've yet to see the successful implementation of a single IT system, and this article seems to advocating this, across a large company over time. Businesses are as much tribes as they are systems and the software has to be able to cope with that as well. Oh, and any good business worth its salt shouldn't be telling a contractor too much about how it actually makes money.

[Dummy00001]

The obvious

"[...] and often mutual incomprehension."

And the obvious, most common, option is missing: architects are there blow the budget, while business wants it cheaper.

As result, very often projects end up being over-designed (architects and designers tried to show off, create more "work" for the software houses) and under-budgeted (because to close the deal unrealistic lower price was agreed).

[Tim Parker]

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..

[disgruntled yank]

System Thinkers Systematically Theorize System Theory, I Think

I am reminded of the delight & relief with which I got got rid of a big fat report from a local consulting firm--the flavor of the month was SOA buses, not business capabilities back then.

But Capability Brown would be a fine name for a software architect...

[Christian Berger]

Never put complexity into code

If you need complexity put it into data. (those may be arrays in your code)

If you cannot manage to put your complex system into a simple form and a table you will have lost.

[Robert Forsyth]

Re: Never put complexity into code

http://dilbert.com/strips/comic/2013-04-10/

[Anonymous Coward]

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?

[Anonymous Coward]

Forgot the footnote

[1] Forbes, WSJ, Money, etc. - the sorts of magazines CEOs and CEO-wannabes spank off to in the executive bathrooms.

(and I didn't catch that I'd forgotten until after the edit window closed).

[Anonymous Coward]

Two sorts of IT - business conversations

There are IT - business interfaces where IT bod is all problems and keeps saying you cannot have something for some bureaucratic reason: "You cannot put your new web-service on an internal test area of the server farm, until it has been tested."

Then there are IT bods who just get on with it.

From my limited analysis,

The first types either like procedure and petty rules, or have been burnt by business side using them as scape goats. They fail to realise, that although most things in business are a service, it is a service with a human touch, i.e. adaptable and courteous. Why do offices have coffee, flowers, or windows? Why would you insist every one has the same desktop wallpaper? Why create a form which has to be fully completed or fully rolled back, before exit, for the sake of a couple of values which need research at another time, all the work putting the rest of the values in is wasted.

The second types of IT people are trusted to delivery a system/solution in a reasonable time-scale and reasonable budget. They listen more than they talk. But perhaps more importantly, they understand the capabilities and needs of the people they deal with. Also, they take responsibility while making sure they can backtrack any implementation. I guess they also manage the requester's expectation.

However, you can still get a system which is too flexible and needs too much (re)configuration to get any useful work out of it.

[Anonymous Coward]

Re: Two sorts of IT - business conversations

Two sorts of IT: Ones who know what they are doing and feel (for whatever reason) they are your servants. Ones who know what they are doing and know they are smarter (at least in certain areas) than you and "get on with it" in a way that you won't notice that they didn't give you want you specified but what you actually needed.

So try to lift up the first type - if you can. Have respect for the second type.

There is a third type though - the poser. If you cannot work with the first two, you'll get along swell with the third.

[meno]

Good IT isn't about buzzwords, it's about people

"Few software architects are business domain experts"

So fire them and hire ones that are.

Seriously. Good IT isn't about buzzwords or "Disruptive Architecture". It's about people.

[Roland6]

Systems Thinking

This article and other recent pieces on Enterprise & IT Architecture concerning the applicability of systems thinking just go to show how far ahead Peter Checkland was in his thinking - creating the Soft Systems Methodology (SSM) in the late 1970's - and how his work has stood the test of time. Peter's work, (along with Enid Mumford's) has been one part of my degree that I have used extensively in my career.

If you are serious about working in the design space I highly recommend you gain a working understanding of his work as it is far more relevant than general systems theory, which it seems Mike Lloyd in his article is alluding to.

[Spearchucker Jones]

Re: Systems Thinking

Interesting, and thanks - I've not come across SSM before. A lot of what (how) I do comes from McKinsey and the management consulting world. One book that covers a lot of the non-technical aspects [1] that I've gotten a lot of use from, is Designing Solutions for Your Business Problems (http://www.amazon.co.uk/dp/0787967653). There's a lot that book doesn't cover though [2], so thanks again for mentioning SSM.

[1] Understanding the current environment (includes policital landscape), setting objectives, building relationships, establishing scope, and so on.

[2] That book focuses on solving business problems. That's close to using technology to solve business problems, but not quite the same thing. The book also doesn't cover things like conflict management or negotiation, both of which I think are part of the core skills a good architect needs.