Artwork of the Enterprise and Solution Architecture
An artwork is an object that may have an aesthetic and/or conceptual value.
Some would define it as “physical object”, some would say it is “non-textual object”… I would say, let’s just not limit what kind of “object” it can be…
Are we artists as well?
In my previous article Enterprise Architecture in the era of Agile… I was “bitterly” arguing how Architecture is primarily an engineering discipline.
But…
Yes, it is primarily an engineering discipline, but there is some art in the Architecture? Actually, more than just “some”…
The “real” Architecture (in the construction), was always combination of engineering and art. An Architect was putting his/her signature on the architecture work done. Are we doing that in the IT Architecture as well?
The artistic mind in us - do not like we always comply to specific standards and templates - artists are individualists, and like to see their work to be observed as unique piece of work…
Of course, Architecture is primarily an engineering discipline so it cannot be fully applied… but, there is (and there always be) some “little” artwork in every artifact we produce…
How do we add our own “signature”?
The way how we “envision” things…
An Architect envisions the Strategy, shapes or at least influence it. And Strategy, can go in various directions. How do we share (or influence) the Strategy – no matter how analytical, technical and impartial we try to be – we all are bias – bias because of our habits, because of our experiences, and because of our character.
An Architect is responsible to envision the Solution itself and the Solution Roadmap – and there can be multiple Solutions for the same Problem, and there could be multiple ways how to reach to the desired Solution. Which Solution to choose? Which path to go? In fact, it is very often determined (intentionally or unintentionally) by our own way of thinking – how do “I” envision the Solution of the Problem…What do “I” believe is the best approach… And then, we just catch ourselves building options, proposals, SWOT etc. trying to support our preferred option…
And that normal – right? We can be individualists…
In the “construction”, Lead Architect is signing the final artifact, but it is never work of only one person. There is a long way from the initial vision & visualization to the actual building being built.
In the IT world, artifacts are much more depersonalized – building comprehensive Strategy, Roadmap and the Solution itself, is the collaborative work of many people. There are other Architects, other stakeholders – things are being challenged and impartial options must be provided for the wider community of the decision makers – and decision makers do not necessary recognize “artistic” component of the IT Architecture (as they would see it in e.g. “construction” Architecture),
Even though we do put a little bit of “our own”, IT Architecture is perceived as a teamwork – simply we are not left with too much space to put our own individual “signature”.
And this is also okay – in the engineering we aim toward workable and manageable solution, this is the “control” mechanism, letting enterprise chose its’s best Strategy, Roadmap and Solutions…
The way how we “draw” things…
The way how the Architecture is drawn is mostly influenced by the enterprise tools used, prescribed enterprise standard, enterprise taxonomy in use, governance framework in place etc.
But, there are ways we do things differently – weather we do not comply fully with prescribed enterprise standards by bringing our own tools & habits (“look, this is more clear way to represent…”) – or by deviating & twisting available tools and standard (“I am just bringing some new shapes and colors…”). And in most of the cases, it just works…
The way how we “design” things…
The overall purpose of the Architecture is about providing some specific Solution(s). As said, there can be multiple Solutions to the same Problem, but there can also be multiple ways how to come to the Solution itself.
We differentiate ourselves on:
- How do we “come” to the viable Solution candidate(s)? What is the process we apply? I.e. Design thinking[1] or something else…
- How do we “choose” the proper Solution? Do we pilot or run PoC (Proof of Concept)? Or we rely on the extensive prior experience? Or we just apply Occam’s razor[2]…
Yes, there are many techniques (both in traditional, and especially nowadays in Agile methodologies) to assist the solutioning process, to make it more “teamwork”; but here an Architect (usually SA) has substantial freedom in steering the team into desired direction – after all, many Solutions are too-technical to include non-technical stakeholders in the decision process – important is to solve the Problem. Giving the freedom to an Architect to design Solution is, in fact, quite desired…
The designed Solution must be clearly described to the team which is supposed to implement it – if it obeys some general rules, nobody should really care about choice of color or so.
The way how we “present” things…
Finally, how to we “sell” our artwork (or our teamwork) to the wider public, including decision makers?
The message has to be clear and understandable – no matter if we talk about Elevator pitch[3] or a bit longer form of presentation.
Here, things are getting pretty much individual… This is not so much about engineering, this is about who we are, what we are, and how we do things… Frameworks cannot (really) teach us, experience will shape us…
And it’s not only art, it’s marketing as well – people need to “like” the Solution in order to “buy” it…
Final thoughts
So, are we artists as well?
Do we produce artifacts or artwork? Or both? Maybe this artwork is distinguishing IT Architects from other IT engineers… Or maybe we just want to see ourselves as being different…
In the IT world, Architecture is primarily an engineering work – but there is (and there always will be) some “personal” note we add… Is it sufficient that we can call the artifact to be artwork? In many cases not, but in some cases, I believe yes…
One way or the other, some guidelines in creating IT Architecture artifacts/artwork do apply – and excellent overview can be found in the article Practical guidelines to create great architecture ... - SAP Community Groups by @Rajen_Patel.
Acknowledgment
*) Intro photo by Anders Jildén on Unsplash
References
[1] Design thinking - Wikipedia: Ideating & and do we ideate, 5-Whys and when do we ask it etc.
[2] Occam's razor - Wikipedia: usually (over simplified) paraphrased as "The simplest explanation is usually the best one."
[3] Elevator pitch - Wikipedia: usually very short and “bombastic” form of description
- SAP Managed Tags:
