In this blog post you'll find out ... that design is not (should not be) dead yet, functional architecture is as important as the technical one (and should have an owner), why BABOK sucks big-time, that it's time to pimp your dusted Business Analysts, what I think about User Stories, BPMN, Enterprise Architect - and what are the most sensible replacements for these ;)

Everyone has her/his obsessions, so do I. In my case the list is quite long - the leverage of modern engineering culture on software delivery, infecting everyone with day-to-day Kaizen mindset, (controlled) scaling of complexity in growing software platforms, ... And this last point mentioned here will be something I'd like to focus on in this blog post.

Adding new functionality in software is easy, doing it in a way that it makes sense (& adds value) is much harder. But doing it in a way that keeps the proper balance between the cohesion & coupling requires even more attention and energy - it'd doesn't "just happen, by accident" - someone with a certain knowledge & experience has to look/care about that.

But who?

I'll use the most overloaded term in Software Engineering - Architects! BUT not any Architects - I'd rather call them Functional (or Domain) Architects. It's a role which is all about:

  1. "slicing the elephant" so EACH part has its function & exclusive responsibility, which do not overlap and are defined IN TERMS OF "PROMISE" (contract between the capability provider and consumers) not implementation details
  2. good understanding of what has to be done (to meet feature expectations) & where/how we should add stuff to the current solution - NOT in terms of UI/UX changes, but capabilities/components with dedicated domain functions (described in promises)

Wait. But I don't know any team with an explicit position named "Functional Architect". WTF?

Mainly because it's usually an unnamed role (responsibility), not a position. With an exception of traditional Enterprise Architect (TOGAF-style) which is totally outdated these days & it has survived mainly in large corporations of high inertia.

IMHO being a Functional (/Domain) Architect (F/DA) should be a VERY explicit role, with VERY explicit accountability. It doesn't require any sophisticated technical skills, but it doesn't mean it's for everyone. A good F/DA has to be freakishly good:

  • in general communication - active listener
  • work/knowledge organisation - knowledge can't slip because FA doesn't make notes ;P
  • abstract thinking and structuring things (slice, categorise, look for patterns, draw conclusions, rinse & repeat ...)
  • general curiosity & nosy inquisitiveness :)
  • ability to effectively visualise both problems & solutions (priceless!)

I have no problems with Engineer playing this role, but ... my observation is that many Engineers had a tendency to (un-)consciously switch their main focus to technical aspects of design/composition/integration - which is DEFINITELY not a goal here ("say microservices one more time ...").

All in white ...

That's why I see here a niche for people who are (were?) usually known as Business Analysts (BA).

Historically, this role is tainted (in software delivery industry). Mainly because it's frequently associated with an anti-pattern of creating "Chinese whispers"-style proxies. Basically people who bridge the communication ("translate") between business peeps & IT peeps. As this is considered very anti-Agile, BAs these days have:

  • either joined business units
  • or play the role of "transcribing requirements" into a debilitating form of so-called User Stories

What's even worse - recently I've checked out so-called BABOK Guide - which aspires to be the referential collection of patterns/best practices to follow when it comes to Business Analysis (also in IT). My conclusion is simple: nothing has changed there since the late 80s, this is as outdated as it can be, abysmal pile of dung - it completely ignores EVERYTHING brought to the table by the evolution of design paradigms in last 20 years! Just a bunch of examples:

All the other roles involved in building software products (QA, Infrastructure, even Managers ...) have made a quantum leap in terms of how they fulfil their obligations - it's the highest time to get more up-to-date for the BA role as well. Fortunately there are many people (and organisations) that are doing that in a very aware way, but frankly - I have a feeling it's still the minority.

I find it important not because of my obsession mentioned in the very beginning of this blog post, BUT also because I've personally played a role of BA (full-time & part-time) for several years of my professional career - I dare to say I've learned shitloads due to my own mistakes & wrong decisions and I was able to honestly assess (also from the perspective of time passing by) the value I've added.

Modern Analyst

OK, let's get to the point there - WHAT should the role of an Analyst be about?

  1. stop talking about Business Analysts (this suggests their bond to business unit) - think Functional (or Domain) Analysts & Architects (F/DA) instead. Naming IS important.
  2. F/DA have to be members of delivery teams, co-accountable for the effect of the whole team's work outcomes.
  3. their role is split into 2 clear (& equally important) parts - facilitation of the collaboration on the expectations ("requirements", opportunities, promises) AND development of the functional architecture of the solution.

The FIRST part is much more than formalising the User Stories ("As ... I want ... So that ...") or even supporting it with visual notation of choice (e.g. BPMN ;P):

  • turning expectations & "acceptation criteria" in executable specifications (e.g. BDD-style)
  • mining knowledge (this is what even legacy BAs were good about ...) AND sharing this knowledge (so it doesn't stay in your brain only) - User Story is only a sample product (very limited view) of this knowledge processing!
  • identifying WHY behind every slightest, proposed change - maybe we can provide the same value in much more cheaper/simpler/future-proof way - be an Analyst, not a Chronicler!
  • involving all the interested parties instead of being simply a proxy

The SECOND part is totally about:

  • "slicing the elephant" (into non-duplicated, separate functional areas that can be considered separately & provide separate "promises")
  • Living Documentation as a principle!
  • FUNCTIONAL (DOMAIN) architecture - which (in contrary to the common beliefs) is VERY far from data model
  • not duplicating the information in the code (at least w/o validation)! this would never be maintainable - and everything that is not maintainable effectively renders F/DA work USELESS
  • concepts (e.g. split sub-components) you use HAVE to correspond to the real solution: e.g. if you use the term "package" (because it's in UML), but the solution doesn't contain packages (but "modules" or "containers") - you've failed! in other words: your "language" have to be ubiquitous for both: technical & domain dimensions
  • knowing how deeply to get down - the functional architecture DOESN'T have to answer ALL the questions, but the ones it does, it has to answer correctly and unequivocally
  • different levels of details on the different level of abstraction - having 1 shared model of everything will work only for very small solutions (without a chance of scaling up) - get up-to-date with the concepts of: sub-domains, bounded contexts, context maps, etc.
  • being 100% understandable - notations like BPMN or ArchiMate have failed (to achieve mass adoption) for a reason - they may have worked for internal purpose in small communities of people using them on the daily basis, but they are overly complex AND still - far from being flexible enough to cover all the contextual specifics; focus on simple, approachable visualisations like: C4 model, "circles & boxes", flowcharts, the most basic UML diagrams (class/object, state, communication) - even different kind of arrows in class diagram are usually too unclear; it's like with code: optimise it for reading (& readers), not for writing (& writers).
  • realising that Functional Architecture is not only YOURS to shape - you're just leading the efforts; the usual failure here is e.g. using the tool only you can use (because it's expensive or has a high learning curve) - I did this mistake with Enterprise Architect & few other tools in the past. What does ALWAYS happen in such case? Other people (your stakeholders) momentarily lose interest in this model they consider YOURS - it stops playing its role & you're in the never-ending (& hopeless) chase to keep it up-to-date, while no-one cares (anymore).
  • being unconditionally pragmatic - the artifacts you create do not contribute to the end-users' value DIRECTLY, so it's easy to get over-board & over-blow the artifacts you're working on (e.g. produce too much or redundant stuff). Which only means more effort to maintain it in future, without delivering additional knowledge. It's simply a waste - so you better get a feedback and confirm the purpose of each artifact.

Conclusion

OK, this blog post apparently got a bit out-of-control :) It's the high time to stop starting & start finishing ...

My conclusion is that EACH product should have a Functional (/Domain) Architect & each team should have a Functional (/Domain) Analyst. This role is NOT about documenting the code (or data model) pre- or post-factum. Quite the contrary - this role is VERY pro-active and is about shaping the Functional Architecture (in advance & in sync with the technical design) in such a way that:

  • development agility doesn't drop - team can make platform adjustments with local (point) modifications, without a need to turn half of the code-base upside down
  • certain non-functional qualities (like maintainability, scalability, performance) can be secured and provided
  • different levels of abstractions are fully comprehensible for interested stakeholders - e.g. team members can easily understand their team's area, Product Owner / Functional Architect of the whole application can understand & develop it w/o getting down into very deep details

All of that with a proper attitude & laser-sharp understanding of the co-responsibility (for the final result - product in the hands of the users). And backed up with the knowledge of modern practices: incl. living documentation, cohesion VS coupling, Domain Driven Design, Systems Theory.

Share this post