Solutioning vs. Solution Architecture
How my world has come crashing down! I now realise that what I once thought of as the summit of crowd-source knowledge – Wikipedia – is nothing but a second rate imitation of genuine academia. The true source of real, absolute truth is urbandictionary.com.
For example:
Solutions Architect is one of a number of job titles used for someone working in IT who has no real function.
Solutions Architects wander around looking important and can often be seen in meetings although no one is quite sure why they are there.
Clearly, the originator of this definition has extensive experience in IT.
At this point, those of you who think I’m serious might want to look up:
I ended up on the Urban Dictionary by looking for definitions of “Solutioning”; in this case I think the Urban Dictionary might be right on the money:
A word many business people misuse to describe the process of creating a solution. These people need a grammar lesson and should be fired immediately.
“I am an idiot so I will spend my day solutioning a way to deal with my stupidity.”
Well, maybe I’m being a bit harsh. Putting the Etymology aside, what I want to discuss here is the difference between the concept of “Solutioning” and what’s (perhaps more formally) known as Solution Architecture.
What do I mean?
In simple terms, the difference is adherence to context: are you taking existing standards, technologies and constraints into consideration. If you aren’t you are Solutioning – you’re coming up with a solution that possibly ignores things it should be paying attention to. If you’re taking these constraints into consideration (and are making use of them) you are engaging in Solution Architecture.
Solutioning:
 |
Solution Architecture / Architecting:
 |
As you can see - when architecting you have to work within constraints.
This problem isn’t specific to architecture; we can also observe this at a lower level (software development) and in other places, other industries, business and social settings – basically anywhere.
An Example: Software Development
Lets say I asked you to develop a small piece of code that took a number between 1-12 and provided the name of the matching calendar month (e.g.: 4 = April).
Have you envisaged it yet? If you have, you just engaged in Solutioning; alternatively, if you immediately started asking questions around possible constraints you’re thinking architecturally.
For starters (and in no particular order):
- What technology / language will this be developed in?
- Assuming we’re adding this to an existing system – is there any code that does this already? Is there a particular place where it should go? Do you have libraries of common functions?
- Is what you’re doing actually offered out-of-the-box by the technology you’re using? Maybe you don’t need to write any code at all.
Nothing exists in a vacuum, and no software is an island; there are always existing things which need to be taken into account.
The real challenge of Solution Architecture
It could be argued that anyone can come up with a solution to a problem, the real trick is “getting it right” in a larger context; so you actually have three things to worry about:
- Coming up with a solution that actually works (and meets the functional needs).
- Ensuring the solution not only works, but also appropriately meets the non-functional requirements (or “illities”).
- Doing all this within the existing constraints, specifically leveraging what’s in the technical landscape and adhering to technologies and components approved by the Enterprise Architecture.
The word “constraint” often has a negative connotation – it implies the options available to you are only a sub-set of all the options available. Bearing that in mind, on the surface it might appear that having to fit in with an existing set of technologies and systems is nothing but a burden, however, it’s not a one-way street; existing systems can be leveraged, homogenous technologies are more easily integrated, more easily exposed, more easily managed, and the result is more structurally sound.
This is the true value of architecture, and also relates to what architects in civil engineering have to contend with: like buildings, IT systems always exist in an environment, and providing a solution that aligns with (and supports and extends) that environment is obviously preferred. That environment includes the obvious visible constraints as well as standards (such as mandatory regulations), the business context and so on.
How hard it is to actually do this is another matter entirely, sometimes some things clearly need to take precedence over others. At least, if you keep the difference between Solutioning and Solution Architecture in mind you’ll stand more chance of asking the right questions, making the right decisions for the right reasons and being able to justify them.
|