Aggregated enterprise architecture wisdom
Still somewhat in catch-up, so here’s another somewhat-late collection of Tweets and links – usual categories, after the usual ‘Read more…’ link.
Enterprise-architecture, business-architecture, business-strategy and all manner of business-related stuff:
oscarberg: RT @dcarli: Investors Don’t Care About Sustainability… Yet Accenture’s recent study w/ the U.N. confirms that CEOs do http://www.bit.ly/aH5dfg <important for #entarch – another side […]
Running way late on the weeklies – apologies. Usual categories, anyway, after the usual ‘Read more…’ link.
Enterprise-architecture, business-architecture, all that kind of stuff:
SAlhir: innovation is less abt product & more about culture RT @jorgebarba @ovoinnovation real product of #innovation http://ow.ly/1rqENf
oscarberg: RT @raesmaa: HBR: Stress-Test Your Strategy http://bit.ly/aFst5a <recommend #bmgen #bizarch #entarch #collab
CreatvEmergence: The Meaningful Organization: […]
I frequently find that there is much confusion about the modelling of Behaviour in an Enterprise Architecture model, specifically between the concepts of Business Capability, Business Function and Business Process. The various enterprise architecture glossaries all differ in their definition of these. For example the TOGAF ADM or ISEB definitions don’t help as much as […]
(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 …
(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.
(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 …
(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.
You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major po…
You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major po…
You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major points on the upward curve of software evolution.
And while neither human evolution nor software advances in correctness are as linear or as easily charted as the graphic suggests there is a similarity between them where highlights from a particular tree become visible from a single point in time, like now and to me.
Starting with Structured Programming – this was a breakthrough in code maintainability where similar logic or logic related to similar data was modularized for easier understandability. Without such an approach if/then/else clauses spanned many pages, making a code base nearly impossible to debug in a timely manner much less to hand off to another developer.
Objects overcame the division between separating code by logic or by data by allowing the developer to combine them both into an object, a single entity.
While this was a revolution to those in the craft of writing code it only helped those writing code to understand their world better and outsiders were not usually part of the arrangement of objects, class diagrams and activity diagrams notwithstanding.
Services and processes were the first entities (in this tree) to be of concern outside the development community. They could be thought of as directly supporting the business. They could be socialized and discussed by subject matter experts and process owners. Although services could be placed in repositories and called by other services and SOAP vs. REST could be argued by the technology community these were sub-plots to what was going on. And what was going on? Software usage was mushrooming and becoming a management problem that wouldn’t go away.
In other words, software was experiencing catastrophic success.
In the late 90s and early 2000s the DoD came upon the concept of capability. Each branch seemed to have its own take on how to utilize the concept and in the current DoDAF capabilities have their place in the DoDAF meta-model.
I’m here to tell you that the story doesn’t stop there. While having a meta-model is critical to keeping your feet on the ground there’s a lot more to capabilities than that.
In short, we at SenseAgility Group, are offering a Capability Based Business Architecture course that draws its inspiration from such things as IEEE 1471, MIT Sloan’s Business Operating Model, UML, BPMN, Archimate, & TOGAF. This means that we provide, through a succinct capability lens, a way to connect architecture with business architecture on a cost and value basis. Not only that but we can connect process, organization and risk/security issues in the same way.
This allows management at any level to organize software and invest in it according to their strategic plan or even to develop a strategic plan using capability based analysis. That last idea, btw, is what the Capability Portfolio is all about.
DPT
I’ve been a huge fan of architecture modeling for over a decade now. I feel there is no better way to get stakeholders on the same page so quickly. It is true what they say…a picture is worth a thousand…
I’ve been a huge fan of architecture modeling for over a decade now. I feel there is no better way to get stakeholders on the same page so quickly. It is true what they say…a picture is worth a thousand words (or meetings). I feel consistent notation…