Software designers: Lose your inhibitions, embrace complexity

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.

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

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.

Taxing

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

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.

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

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

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

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.

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?

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.

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.