bpmn

Business Capability Naming and Content

by

Bruce Silver, BPMN luminary, has recently posted a piece on BPMN and Business Architecture where, he says, “In the past year the ‘architects’ seem to have discovered BPMN.”  WIth his usual meticulous style he dissects the difference between a process and other notions such as capabilities and functions, terms that architects like to throw around in their paperwork.

He clearly distinguishes process as the “how,” which is what we, at SenseAgility, have been saying as well. Process diagrams, and BPMN diagrams in particular, are the proof behind a particular type of capability, namely the Business Capability. In our work we’ve found that there are specific types of acceptable proofs behind different types of capabilities.

Here’s a statement Bruce makes about typing or perhaps it is even about granularity by implication, “If you’re sorting things into boxes, it doesn’t matter so much if some boxes hold square pegs and others round holes. But when you want to assemble those boxes into a coherent unit, it would be easier if the pegs and holes all had the same shape.” To us this principle is exactly the same one we employ when naming capabilities. As mentioned above, capabilities are different types. You can tell they are different types by looking at the proof behind the capability. That is, what makes the capability a capability in the first place? Business Capabilities have processes behind them, maybe more than one, but at least one.

So what I’m saying here is that if you want to give a name to a capability you need to have something in mind besides appropriate wording. Just getting people to agree on words doesn’t cut it. Why? Because ultimately you need to be talking about something of value. If capabilities can’t be linked to something of value then you might be imagining capabilities in a vacuum.

Anyway, subscribe to Bruce’s excellent blog when you get a chance.

ArchiMate, BPMN and UML together

by

The question about “the remaining role of UML now that ArchiMate has arrived” generated an interesting discussion on ArchiMate LinkedIn group. Adrian Champbell‘s first comment was: Archimate was deliberately designed to be mappable to BPMN and UML, but not to replace them. Not parallel universes but complementary ones. Archimate is for modelling at an Enterprise […]

The toolset-ecosystem

by

This one extends the models-for-enterprise-architecture theme from the previous post. Although for me this theme goes back a long way, the start-point here was a Tweet from Dutch EA consultant Martin van den Berg (@bergmart) that triggered off a veritable flurry of replies:

bergmart: I’m more and more convinced that it should be forbidden to show […]

What Business Architecture and Pudding Have in Common

by

(this is a response to the recent article in Architecture and Governance Magazine titled ‘Archimate: Adding Value to TOGAF’ – registration required.)

I was walking down the hall last week when the VP of Finance stopped me and asked me for my latest BPMN and Archimate diagrams for the “X” project that was going to revamp the marketing campaign software. He wanted the diagrams on his desk as soon as possible. If this sounds likely then you and I have probably had different work experiences, not to mention career paths.

I would suggest that the vignette in the previous paragraph is as likely as finding a shovel in Louis XV’s ballroom. So why is it that the good folks at TOGAF and Archimate keep trotting out Archimate viewpoints for EA and Business Architecture?

My answer would be that they’re fascinated by the tools of proof. These tools like Archimate, BPMN, UML are some of my favorite tools. But really, to expect others to have the same enthusiasm is unrealistic.

The business people that I know just don’t care about the actual diagrams although they might be interested in the proof or at least the fact that I have some proof in my pocket somewhere. I’m talking here about the sponsors, the people with the ultimate financial authority, the P&L owners, the ones sponsoring the business architecture (strategy) assignment.

If you’re thinking, “they should be interested” or that “we’ll educate them regarding our super great notation so that we can communicate” then I have to suggest you’ve missed the mark already.

No, the folks I know just want verify that I understand their issues. How I talk to them is critical because they listen to me repeat back to them my own understanding prior to the presentation of strategy options. I do use models behind the scenes to verify my understanding and to provide a backbone to my strategic chat but I talk to the operational people to acquire that understanding. By the way, the operational people are interested in the proof side of the equation but they aren’t the ones making the investment decision.

So the tools of proof are half the story? Well, actually they represent 80% of the work in business architecture. They just don’t show up in the strategy part of the presentation. Actually they don’t show up in the presentation at all, period. But if the tools of proof occupy 80% of the strategy analysis maybe that’s why architecture centric organizations like to call their tools “Business Architecture”. But that is doing what the recruiters do — everything is business architecture to that crowd.

My advice is to make an adjustment where notations are concerned. Keep the details in the background and not the foreground and if you’re selling Business Architecture don’t talk about the tools of proof to your sponsor unless they ask.

To learn more about keeping the proof in the pudding see our Capability Based Business Architecture curriculum here.

What Business Architecture and Pudding Have in Common

by

(this is a response to the recent article in Architecture and Governance Magazine titled ‘Archimate: Adding Value to TOGAF’ – registration required.)

I was walking down the hall last week when the VP of Finance stopped me and asked me for my latest BPMN and Archimate diagrams for the “X” project that was going to revamp the marketing campaign software. He wanted the diagrams on his desk as soon as possible. If this sounds likely then you and I have probably had different work experiences, not to mention career paths.

I would suggest that the vignette in the previous paragraph is as likely as finding a shovel in Louis XV’s ballroom. So why is it that the good folks at TOGAF and Archimate keep trotting out Archimate viewpoints for EA and Business Architecture?

My answer would be that they’re fascinated by the tools of proof. These tools like Archimate, BPMN, UML are some of my favorite tools. But really, to expect others to have the same enthusiasm is unrealistic.

The business people that I know just don’t care about the actual diagrams although they might be interested in the proof or at least the fact that I have some proof in my pocket somewhere. I’m talking here about the sponsors, the people with the ultimate financial authority, the P&L owners, the ones sponsoring the business architecture (strategy) assignment.

If you’re thinking, “they should be interested” or that “we’ll educate them regarding our super great notation so that we can communicate” then I have to suggest you’ve missed the mark already.

No, the folks I know just want verify that I understand their issues. How I talk to them is critical because they listen to me repeat back to them my own understanding prior to the presentation of strategy options. I do use models behind the scenes to verify my understanding and to provide a backbone to my strategic chat but I talk to the operational people to acquire that understanding. By the way, the operational people are interested in the proof side of the equation but they aren’t the ones making the investment decision.

So the tools of proof are half the story? Well, actually they represent 80% of the work in business architecture. They just don’t show up in the strategy part of the presentation. Actually they don’t show up in the presentation at all, period. But if the tools of proof occupy 80% of the strategy analysis maybe that’s why architecture centric organizations like to call their tools “Business Architecture”. But that is doing what the recruiters do — everything is business architecture to that crowd.

My advice is to make an adjustment where notations are concerned. Keep the details in the background and not the foreground and if you’re selling Business Architecture don’t talk about the tools of proof to your sponsor unless they ask.

To learn more about keeping the proof in the pudding see our Capability Based Business Architecture curriculum here.