Aggregated enterprise architecture wisdom
Douglas Paul Thiel Entrepreneur: I have this great idea for a website. I know it’s going to make a ton of money.Developer: I know [python, .NET, Java, Ruby]. I’ve done this before.Entrepreneur: I can see that you have, great. Let’s get started.The entrepreneur, tru…
Entrepreneur: I have this great idea for a website. I know it’s going to make a ton of money.
Developer: I know [python, .NET, Java, Ruby]. I’ve done this before.
Entrepreneur: I can see that you have, great. Let’s get started.
The entrepreneur, trusting the developer, begins to feed him a couple of ideas. The developer asks questions whenever they get stumped. Weeks and/or months later, behold, a website arises!
But this is not the happy ending – it’s only the beginning. Now the fun part begins.
Because when the entrepreneur gets close to some potential enterprise customers and they ask about such mundane concerns as security, integration and website customization. Uh, what? Worse, they want monitoring and tracking – as does the entrepreneur since he needs reporting on a per/customer basis to understand sales and site usage.
Only the developers have since checked out – either physically or mentally. They weren’t interested in maintaining the site. Their brilliance is only appropriate to building the site. Too bad they never did any maintenance programming, ever. If they could have seen the brilliance of others their effort may have been the better for it.
Now what? It’s unusual for developers to document well in such circumstances, and the entrepreneur doesn’t read [python, .NET, Java, Ruby], nor is he particularly interested in learning how to read them. Of course he could hire someone who does but then he knows how that turned out.
On the plus side, what the entrepreneur has, is a demo capable website. He can sell it. And, with luck, it’s a stepping stone to something that will stand up to the heavy traffic required to make a “ton of money.”
The problem is that without an analysis of client needs against the strength of the code he doesn’t know. Even if all is well, he knows he has to take a step back to take two forward.
But all is not well – even a cursory analysis shows that the code is not rationalized on the back end – because there is no back end. All the code is in the equivalent asp/jsp server, meaning that, in the end, testing costs will be much higher for changes than is sustainable. All the website text is embedded in the code which equals the need for changes and that there’s no way to easily customize the site to each customer’s content requests. There’s no service or facility to upload large data sets for the corporate customer. There’s no separation between the primitive reporting interface and the operational data store meaning that every time the entrepreneur wants a report it will impact his site’s performance. Oh, and tokens representing sign-on are sent in the clear, and that’s the extent of the security framework. This, in turn, limits the entrepreneur’s top line revenue possibilities, as larger and more established companies require these issues to be addressed prior to considering a purchase or licensing agreements.
At SenseAgility we’ve seen this pattern over and over. It’s not necessarily wrong – it is even encouraged by the Private Equity community who is more interested in a smaller up-front investment than long-term viability. The entrepreneur does have a functional website that he can sell and that might even support a few customers. But by this time, they have usually invested several hundred thousand dollars into what is essentially a throwaway. Was it worth the investment?
You decide.
Entrepreneur: I have this great idea for a website. I know it’s going to make a ton of money.Developer: I know [python, .NET, Java, Ruby]. I’ve done this before.Entrepreneur: I can see that you have, great. Let’s get started.The entrepreneur, tru…
Entrepreneur: I have this great idea for a website. I know it’s going to make a ton of money.
Developer: I know [python, .NET, Java, Ruby]. I’ve done this before.
Entrepreneur: I can see that you have, great. Let’s get started.
The entrepreneur, trusting the developer, begins to feed him a couple of ideas. The developer asks questions whenever they get stumped. Weeks and/or months later, behold, a website arises!
But this is not the happy ending – it’s only the beginning. Now the fun part begins.
Because when the entrepreneur gets close to some potential enterprise customers and they ask about such mundane concerns as security, integration and website customization. Uh, what? Worse, they want monitoring and tracking – as does the entrepreneur since he needs reporting on a per/customer basis to understand sales and site usage.
Only the developers have since checked out – either physically or mentally. They weren’t interested in maintaining the site. Their brilliance is only appropriate to building the site. Too bad they never did any maintenance programming, ever. If they could have seen the brilliance of others their effort may have been the better for it.
Now what? It’s unusual for developers to document well in such circumstances, and the entrepreneur doesn’t read [python, .NET, Java, Ruby], nor is he particularly interested in learning how to read them. Of course he could hire someone who does but then he knows how that turned out.
On the plus side, what the entrepreneur has, is a demo capable website. He can sell it. And, with luck, it’s a stepping stone to something that will stand up to the heavy traffic required to make a “ton of money.”
The problem is that without an analysis of client needs against the strength of the code he doesn’t know. Even if all is well, he knows he has to take a step back to take two forward.
But all is not well – even a cursory analysis shows that the code is not rationalized on the back end – because there is no back end. All the code is in the equivalent asp/jsp server, meaning that, in the end, testing costs will be much higher for changes than is sustainable. All the website text is embedded in the code which equals the need for changes and that there’s no way to easily customize the site to each customer’s content requests. There’s no service or facility to upload large data sets for the corporate customer. There’s no separation between the primitive reporting interface and the operational data store meaning that every time the entrepreneur wants a report it will impact his site’s performance. Oh, and tokens representing sign-on are sent in the clear, and that’s the extent of the security framework. This, in turn, limits the entrepreneur’s top line revenue possibilities, as larger and more established companies require these issues to be addressed prior to considering a purchase or licensing agreements.
At SenseAgility we’ve seen this pattern over and over. It’s not necessarily wrong – it is even encouraged by the Private Equity community who is more interested in a smaller up-front investment than long-term viability. The entrepreneur does have a functional website that he can sell and that might even support a few customers. But by this time, they have usually invested several hundred thousand dollars into what is essentially a throwaway. Was it worth the investment?
You decide.
(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
The Open Group committee made a conscious choice to encourage customization of TOGAF, since every organizational context is unique. After all, TOGAF is a framework, not something you swallow whole to get well. If you look at the first BPMN sub-pr…