As I’ve noted previously that to my best knowledge there is a definitive lack of a holistic approach to enterprise solutions engineering. I’ve even coined a name for such an approach — Solutions Acquisition Framework or SAF. I’m doing a research — well, googling — in order to find if someone have already came up with something similar or at least that could be reused as part of such framework.
Surprisingly, I’ve found materials that speculate on the similar problem coming out of… Microsoft. It might be my own prejudice, but I’ve never considered Microsoft to be a source of inspiration when talking about enterprise IT, apart from being a default choice for office productivity solutions, e.g. Windows, Office, Exchange, etc. Well, arguably .Net Framework got some traction in the industry; however it’s still mostly in client-side department for most enterprises I’ve heard of.
I’ve found a blog post by smart Microsoft guy Hatay Tuna where he notes the same methodological vacuum as I did, using almost the same words (the blog itself is, unfortunately, abandoned):
[…] there are methodologies which are at OOD level, just focus on development, or other complicated ones for enterprise architects but it’s always a challenge to find some thing in the middle one level higher that SDLC, one level lower than Enterprise Architecture.
More than that, he provides what I’d call a reference model for enterprise solutions engineering, because it highlights the context and principal moving parts of the domain. Amusingly, the title for the post is Solutions Architecture Framework, which has the same acronym as my own Solutions Acquisition Framework. I dare to replicate the picture in this post.
Interesting things to note here from my point of view:
- Lean-style pull of business value shaped by business drivers is very important. It shapes the whole engineering process. It also implies that there’s a need to trace requirements and design decisions up to business drivers.
- Both business vision and technical vision define a context for a solution from the enterprise architecture perspective. It is major organizational interface that is completely uncharted in current breed of EA methods.
- Loops (2.A) and (2.B) are bidirectional. Not only business architecture shapes solution (alignment), but solution feeds prospective capabilities back to the business architecture baseline. The same for technical architecture. In fact, a balance needs to be found, as there is a danger of over-constraining the solution as well, as giving it too much space to maneuver.
- One aspect that I’ve found missing here is procurement of off-the-shelf products. Or rather not missing but folded into the solution architecture activity box. What I’ve found that capabilities available on the market shape solutions to certain extent (and business/technical architectures indirectly — as per 3). The less commoditized product you are looking for, the more surprises and impact in general you should expect. Therefore, it is significant constraint that have to be taken into account by the architect.
Each of these worth separate addressing and elaborating, which I hope to cover in due course.
In addition to all above the post refreshed my memories about something called Microsoft Solutions Framework (MSF). I had a quick look and got a surprise. Amazingly, it seems that the Microsoft managed to come up with an organizational model for a solution delivery project which is essentially Lean years before Lean and Agile started to gain momentum in the industry. For example, the MSF Team Model suggests that solution team have to include not only usual suspects (architects, developers, QA people, project management, etc.), but representatives of other stakeholders such as IT operations and end user support as well. Hell, the first version of MSF saw the light in 1993, and these ideas are still bleeding edge for most companies out there.
Well, I know how it happened. Apparently, because of the desktop focus and, hence, proximity to end users, who by coincidence are business users as well, Microsoft architects got more exposure to business reality than their back room fellows (as myself). Apparently a synthesis happened somewhere in depths and this is what the result was. Quite impressive. It’s a shame that the industry in general doesn’t pay heed to the legacy of the past proven experience and goes down the (usual) reinvention route.
Anyway, I’ve got an MSF Essentials tome on my bookshelf, so a review and learned lessons are to follow.
Enterprise Systems Engineering 