Executable enterprise architecture
Just come off the phone from an excellent conversation with Sigurd Rinde, developer of Thingamy – brilliantly summarised by Hugh ‘gapingvoid’ MacLeod on 30megs.com (“Here’s 30 megs. Now go run Germany.”)
Key point is that it connects exactly with whole-of-enterprise architecture: the architecture analysis phase – the ‘enterprise ontology’ – leads directly to enterprise software for information/process flow. So it’s not just ‘actionable enterprise architecture’ – to use a current popular buzz-term – but executable enterprise architecture. A few of the existing enterprise architecture toolsets are starting to get somewhere close to this – EVA NetModeler from Promis being perhaps the best example – but this comes at it from another direction entirely, and a more immediately usable direction at that.
That’s just the start. The key aim of Thingamy is to tackle the complex, near-chaotic, barely-repeatable process-flows that businesses really use in most of their work, and which to date have barely been addressed by existing enterprise software, precisely because they don’t fit the usual clunky true/false logic. The real-world processes that people use, in fact. Sigurd suggests that something like two-thirds of all business processes fit into this ‘barely repeatable’ category, yet almost all ‘enterprise software’ efforts to date have focussed on the ‘easily repeatable’ end of the scale, precisely because it is ‘easier’ (easier to sell to those who cling onto wistful dreams of ‘control’, too… :wrygrin: ). As with the comparison of analogue and digital – analogue can replicate digital, but digital can never do more than provide a abstraction of analogue – so too are the ‘easily repeatable’ processes merely a limited subset of the real ‘barely repeatable’ ones. So something that’s designed to tackle the ‘barely repeatable’ processes can also do all the ‘easily repeatable’ ones – yet much, much more. Definitely interesting…
To an enterprise architect, one obvious example of a ‘barely repeatable process’ is enterprise architecture itself. With many thanks to Sigurd, I’ve downloaded a copy of Thingamy, and over the next few weeks – time and sanity permitting – will have a go at implementing an executable version of my amended-TOGAF ADM, as one directly useful place to start. Watch this space?
[Many thanks to Sally Bean for her initial pointer to the 30megs site, by the way.]
Hi Tom
Do these guys have a definition that would help me understand the practical difference between “actionable” and “executable”?
Hi Richard
‘These guys’ is actually me 🙂 – I came up with the idea during the conversation with Sigurd.
An ‘actionable EA’ is a plan or blueprint that you can use for building usable real-world designs – as opposed to unusable ‘shelfware’, which was the common fate of many earlier, more ‘academic’ styles of EA.
An ‘executable EA’ is one where the enterprise process / information / value etc model is constructed in such a way that it can be used _directly_ , as executable software, in real business processes. The model _is_ the software.
In a way, this is what BPMN > BPEL modelling aims to do, but it only works for what Sigurd describes as ‘easily repeatable processes’ (‘ERP’). As explained in the 30megs.com summary, what Sigurd has done is focus on the more common ‘barely repeatable processes’ (‘BRP’).
Classic TOGAF and other IT-centric approaches to EA fit well with the ERPs, but for most part gloss over the BRPs, throwing them into the magic ‘too-hard basket’ labelled ‘manual processes’. If we do EA properly, as an architecture of the enterprise rather than solely its IT, we should end up with a model in which parts at least will map directly into Thingamy’s design-approach – in effect, a BPEL for the BRPs rather than solely for the ERPs.
I’ll freely admit it’s still more an idea or vision than anything else, but the idea of an ‘executable architecture’ already exists in BPEL and OMG’s MDA and the like, and Sigurd’s software is already out there and in regular use. The EA concepts to break out of the IT-centric box also already exist – as you’ve seen in my books and the like. So it does all seem doable: more on this when I’ve had more a chance to ‘get down and get dirty’ with some real development.
Richard,
I’ll let Tom pitch in as it was him that coined the term… 🙂
But for us (Thingamy) executable is a given – build the business model (as how to use resources to create the value your strategy stipulates) then simply run the business.
[Execute with the model builder itself: Start a flow, information + task + tool is distributed to the right person at the right time, all is captured by the tasks/events and report templates gives you any kind of report real-time (or historical) based on the data capture.]
Sig
Also looking forward to Tom’s review. Have too / two interests:
[1] Is Thingamy on the flubbing edge or EEA and,
[2] Importantly, examples of where there is anticipated economic payback in documenting / automating BRP – surely by definition BRP are needed infrequently, have a tendency to change due to external influences? i.e.
[a] the nature of the product / object / outcome expected from the BRP is intended to be different
[b] the players involved would be different,
[c] the raw materials would be different.
Take Project Management as an example – there are principles and best practice but most projects are different. If PM was repeatable it would unlikely be called a project – more likely called a process.
Hi Simon
I’ll have to pass you on to Sig for most of this, but my understanding is as follows:
– BRPs are, by definition, varying in their execution path, but the starting point is (nominally) the same and the end-aim / end-product would often (usually?) be similar (at an abstract level – i.e. class of end-point rather than predefined instance, as in Six Sigma)
– Sig draws a distinction between ‘process’ – i.e. an ERP – and ‘practice’ – which is more like a loosely-coupled set of disciplines: what happens in the middle can take any course and may end up in a different place
– the example I’m aiming to work on is architecture development: it has a defined starting-point (the business-question and business-value description), but everything else from then on is uncertain, with new themes and side-issues likely to develop along the way. To use your terminology, every architecture activity would be a project, not a process.
On your [2], I would imagine that there is probably no point at all in documenting a BRP unless it _is_ a ‘self-documenting executable’. The ‘documentation is a trace of what was done by whom, to whom it should pass next, and so on, towards the intended nominal end-point. A project finishes when someone says it’s finished: there is no previously-defined end-point, as there is with, say, a BPMN/BPEL process.
Beyond those comments, you probably know more than I do. 🙂 Would suggest look again at the 30Megs.com and Thingamy.com sites – or give Sigurd a call, he’ll be happy to explain the underlying thinking that’s behind the toolset. I’s just a workin’ stiff tryin’ to make sense of it, just like anyone else! 🙂 )
Simon (could not hold back when I saw the Project Management term there), let me try to give such an example…
In simple terms for a “Project” certain things are always “in the air” hence making it to a typical running BRP – starting with the “overall project”:
– How many “sub-projects” will you break that into?
– How many “sub-sub-projects” will you break those into?
– How many “subs” (i.e. levels) will there be?
– Which ones can be done in parallel and which follows which?
– Each of the above will have different goals, and tasks lastly, all for different assignees.
Here’s how I do it in Thingamy:
1. Top level flow: Project owner starts the whole thing and defines the project (add details to a Project object).
2. Then he defines the first Sub-project (details added to s Sub-project object) and chooses assignee for that.
3. He then gets the question “Add another sub-project?”, if yes 2. is repeated. Then same question until he’s finished with sending out first round and answers No. Then he has no more tasks until first of the Sub-projects are finished – at which point he can start another or not (project finishes with last No).
4. Those creates each an instance of a Level 2 flow where the assignees gets the objects (all pertinent information and instructions) to see and can choose to do it himself (a task) or split it up again as for level 1.
5. This repeats itself to actual tasks are all finished and it all trickles upward again (each time with a possibility to review for the taskmaster at level above with option to reassign if need be).
A bit iffy that but the result is an infinitely expandable project with options underway to send back to assignee, add new sub-x-projects each time one is finished etc. All that is done will of course be visible instantly.
LOL, seems Tom and I are in perfect sync here…
I think I understand what “executable” means if we are talking about software, or something that can be projected into software. In other words, an IT-centric notion of execution.
But if it isn’t purely an IT-centric notion (and I’m rather hoping it isn’t), then I don’t think I quite understand what “executable” means. Here’s my attempt: executives formulate and execute strategy, managers formulate and execute tactics, workers formulate and execute semi-structured processes. So are we talking about some whole-of-enterprise architecture that formalizes not just semi-structured processes but also strategy and tactics, and makes them all executable in some sense?
Thanks Gents!
Richard
Fair enough, I take your point about “an IT-centric notion of execution” – I’ve complained about IT-centrism often enough, I shouldn’t be promoting it!
What interested me most here was the idea that the enterprise-architecture _itself_ could become part of the IT-executables: the real-world ‘objects’ modelled becomes the basis for process (‘practice’) flow. We already have this kind of notion at a much lower level, and for easily-repeatable processes that are much more amenable to conventional BPMN/BPEL execution; the (to me) exciting point here was that the modelling would directly support the guidance and documentation of the ‘barely repeatable processes’ that TOGAF (for example) dumps into the random grab-basket labelled ‘business architecture : manual processes’.
One of the huge problems in the architecture process itself is governance: who does what, who did what, who is going to do what in what order, and so on. You really need to talk with Sigurd about how Thingamy tackles this – the whole post was on the basis of a chunk of online reading and a couple of hours phone-call with Sigurd, so I can’t really add all that much more. But the point seems to be that ‘execution’ is a much more open affair: the IT is strictly in a support-role, not a driving role. And yes, the start-point for each process (or whatever you want to call it) is based on a _specified_ business-value – much as I’ve been pushing for the architecture-development process.
I’ve yet to work out how to link all of this into the complete whole-of-enterprise architecture frame – I haven’t had a chance to install the software yet, for heaven’s sake! – but you do _know_ that that is my main focus: I’m not likely to throw all of that work, all of that philosophical base, just because some interesting new piece of software has appeared on my radar. I thought you trusted my intellectual and professional integrity a bit better than that: oh well… 🙂
It’s early days: give me a chance to at least get started before you heap on the critique, okay? Other we never will get a chance to get started – and hence wll be stuck once again with the IT-centric bad-joke that still passes for ‘enterprise architecture’ these days. I want _very_ much to get further with this – I trust you do too? In which case please _help_, rather than leaping in on the attack any time anyone thinks even slightly differently from you? Because that _is_ how it feels, y’know… :wrygrin:
Richard, allow me to confuse even more:
a) All organisations/businesses are about sequential work (otherwise why get people together?)
b) A sequence is a flow and no flow can exist without a framework, like a river needs a riverbed.
c) Current framework for people processes/practices are called organisational hierarchies, budgets, deadlines, double-entry book keeping, meetings (cornerstone that) and all the organic group and self “organising” we do from ad-hoc grouping to “have to remember that email” – to-do lists an important part of that. Off site team building camps? Ditto, frameworking again.
d) See Thingamy as an alternative framework for people processes/practices, with enough leeway in forks and loops and choices so it becomes a riverbed and not a pipeline. In fact it does not need, but can mimic if wanted, any and all of the above old framework parts. (My favourite is the dumping of double-entry book keeping, the youngest part of the old framework with only 515 years.)
e) Thus execution would equal starting the flow, rest follows in sequential manner in single file or in parallel flows including loops or forks as deemed necessary by the assignees/participants. Like opening the dam gates at the top of the valley.
On the spot formulating of flows happens when forks or loops are chosen, when participants or objects are selected – ditto with tactics – but the overall riverbed/framework is designed with only one input – the first part of any strategy “what value are you going to deliver?”
With a hospital strategy of “Cure medical conditions” you have the main object – “medical condition” – and other objects like x-ray, surgery, MD, nurse… and patient comes in handy. Then define relations between them. The flow design follows by “how to add value to the main object”, in a flow of course, that’s why it’s a hospital with many people.
So in essence it’s whole-of-enterprise as well as any-little-thing-in-the-corner. And it does not matter where you start as all flows are linked to all others.
In my fuzzy mind I see a business as a ball of yarn… clearly 😉
Hmmmm. Am I losing the plot here – the analogies dont seem to resonate completely with BRP. Sig your sequential riverbed, parallel flows and the project, sub project, sub-sub etc suggest a waterfall style decomposition. Often businesses are not only about sequential work. There are many co-ordination / collaboration, consolidation and desired coagulation (not simply summations) that dont intuitively fit the waterfall decomposition and sequential analogies.
The ‘many’ refers to triggers, tasks, events.
@Simon Modera agree to that, but let me expand:
The example (bad one perhaps) allows each participant to decide during the flow how to handle his task – split it into X sub tasks and distribute or do it himself (as the extremes). Then next level of task assignees can do same ad infinitum. That makes up a BRP friendly system/framework; you do not know beforehand when designing the framework how many splits on how many levels, just allow the participants make the decision when process is underway while the system delivers tasks and info and tools as instructed while capturing all that happens.
Also something to ponder in regards “collaboration”: In essence it always ends up with the question of “how small pieces” do you want to split the process into.
“What is a task?”…
In the classic urge to automate one tries to model every step and will soon hit the wall – ERP works, BRP not.
So far I have not found any “rule”, more a matter of starting with “good sense” then tweak with experience.
In reality a task can be as narrow as to “choose team member” or “answer this question” or as wide as “gather all butterfly species” which would take years and engulf millions of smaller tasks.
Collaboration sometimes mean punting an idea around, having somebody challenge your assumptions – and sometimes it means me do task A followed by somebody else on task B etc. The former I would leave quite open ended into a single task (the owner of the task being accountable) while the latter would be rather strict.
Hi Sig
Your last comments suggest that a useful guideline for creating a new step or sub-task would be when there’s a clear handover of accountability and ‘ownership’. There are possible issues around skill-levels (the equivalent of the detail-level steps in ERPs), but in essence process-management in BRPs is more about governance than anything else: so if the responsibility remains with the same person, there’s no need to create a new step, because the governance remains the same. Would that be correct?