other page actions:
sorted by: recent | see :
popular
Content Tagged complexity
Defense Procurement
Let me start with a couple of quotes from a speech by US Secretary of Defense Robert M. Gates, Washington, D.C., Monday, September 29, 2008.
One point that comes across very clearly from this paper is the opportunity to separate the provision of different layers within a layered architecture. So we may have one set of suppliers providing the underlying layers, and a different set of suppliers providing the upper layers.
The AFEI paper identifies three roles - Platform Providers and Commodity Infrastructure, Component Developers and Enterprise Managers - with what it calls Firewalls between them. (See Figure 3 in the AFEI paper.) These firewalls roughly correspond to the first two of what Philip Boxer calls the three asymmetries of demand. The third asymmetry (not explicitly shown in the AFEI paper) is between the Enterprise Managers and the Customers. (Including customers in the schema is essential if you want to move towards a risk-reward model of procurement, as the DoD evidently does, because it is the customers who ultimately generate the effects.)
Managing all this complexity almost certainly results in higher management cost than if you simply outsource the whole lot to a large system integrator, but it also shifts the management control (architectural governance) back to the acquiring organization.
So which kind of organizations would want to do this then? It's a question of complexity - the greater the level of complexity and volatility in your requirements, the greater the potential benefits from having finer-grained and stratified control over your procurement.
And what kind of organizations are capable of this fine-grained stratified control? Perhaps not too many at the moment, which is why we need a capability maturity model for SOA that provides a roadmap for organizations to develop an appropriate level of SOA capability.
AFEI SOA Acquisition Working Group, "Industry Recommendations for DoD Acquisition of Information Services and SOA Systems", July 2008 (register on the AFEI website for free download)
For explanation of the three asymmetries, see Richard Veryard & Philip Boxer, Metropolis and SOA Governance, Microsoft Architecture Journal, July 2005.
"When it comes to procurement, for the better part of five decades, the trend has gone towards lower numbers as technology gains made each system more capable. In recent years these platforms have grown ever more baroque, ever more costly, are taking longer to build, and are being fielded in ever dwindling quantities."The US Department of Defense appears to have a very clear understanding of the opportunities for Service-Oriented Architecture in enhancing the procurement process and improving the economics of governance. In July 2008, the SOA Acquisition Working Group of the AFEI produced a useful set of Industry Recommendations for DoD Acquisition of Information Services and SOA Systems.
"The issue then becomes how we build this kind of innovative thinking and flexibility into our rigid procurement processes here at home. The key is to make sure that the strategy and risk assessment drives the procurement, rather than the other way around."
One point that comes across very clearly from this paper is the opportunity to separate the provision of different layers within a layered architecture. So we may have one set of suppliers providing the underlying layers, and a different set of suppliers providing the upper layers.
The AFEI paper identifies three roles - Platform Providers and Commodity Infrastructure, Component Developers and Enterprise Managers - with what it calls Firewalls between them. (See Figure 3 in the AFEI paper.) These firewalls roughly correspond to the first two of what Philip Boxer calls the three asymmetries of demand. The third asymmetry (not explicitly shown in the AFEI paper) is between the Enterprise Managers and the Customers. (Including customers in the schema is essential if you want to move towards a risk-reward model of procurement, as the DoD evidently does, because it is the customers who ultimately generate the effects.)
Managing all this complexity almost certainly results in higher management cost than if you simply outsource the whole lot to a large system integrator, but it also shifts the management control (architectural governance) back to the acquiring organization.
So which kind of organizations would want to do this then? It's a question of complexity - the greater the level of complexity and volatility in your requirements, the greater the potential benefits from having finer-grained and stratified control over your procurement.
And what kind of organizations are capable of this fine-grained stratified control? Perhaps not too many at the moment, which is why we need a capability maturity model for SOA that provides a roadmap for organizations to develop an appropriate level of SOA capability.
Sources
AFEI SOA Acquisition Working Group, "Industry Recommendations for DoD Acquisition of Information Services and SOA Systems", July 2008 (register on the AFEI website for free download)
For explanation of the three asymmetries, see Richard Veryard & Philip Boxer, Metropolis and SOA Governance, Microsoft Architecture Journal, July 2005.
soa
sector
complexity
procurement
maturity
asymmetry
defence
More Flattery for the Finance Sector?
CIO Magazine and the SOA Consortium have just announced the results of their Case Study Contest. And the winners are ... (via Brenda Michelson)
The judges have decided to award the overall prize to a company in the finance sector. According to the rubric, this is for a project producing cost-savings of around a million dollars.
Meanwhile, one of the runners-up, a company in the healthcare sector, produced cost-savings of around 6 billion dollars a year.
So why didn't the healthcare company win the overall contest? Were the judges sceptical about the benefits, or did the project did not conform to some technical purist notion of SOA? (If so, it should not have been awarded a runner-up prize either.) I have written to one of the judges asking for the criteria to be published.
I hope to be proved wrong, but I fear this may be yet another example of the SOA industry having a rather distorted view of the finance sector. (See my earlier post IBM Flatters the Finance Sector.) Perhaps one outcome of the current Financial Catastrophe may be that the SOA industry will have to pay a bit more attention to sectors where service-oriented principles can be more usefully applied.
Which are those sectors? In my post Theory and Practice (August 2005) I suggested that the most interesting applications of SOA are going to be found towards the right of the following chart.
I haven't seen anything in the last three years to alter this chart significantly.
The judges have decided to award the overall prize to a company in the finance sector. According to the rubric, this is for a project producing cost-savings of around a million dollars.
Meanwhile, one of the runners-up, a company in the healthcare sector, produced cost-savings of around 6 billion dollars a year.
So why didn't the healthcare company win the overall contest? Were the judges sceptical about the benefits, or did the project did not conform to some technical purist notion of SOA? (If so, it should not have been awarded a runner-up prize either.) I have written to one of the judges asking for the criteria to be published.
I hope to be proved wrong, but I fear this may be yet another example of the SOA industry having a rather distorted view of the finance sector. (See my earlier post IBM Flatters the Finance Sector.) Perhaps one outcome of the current Financial Catastrophe may be that the SOA industry will have to pay a bit more attention to sectors where service-oriented principles can be more usefully applied.
Which are those sectors? In my post Theory and Practice (August 2005) I suggested that the most interesting applications of SOA are going to be found towards the right of the following chart.
| Simple Interoperability | Moderate Interoperability | Complex Interoperability |
| Financial Services Retail SupplyChain Logistics (Basic) Travel | Automotive eGovernment SupplyChain Logistics (Advanced) Telecoms | Aerospace & Defence Consumer Electronics Healthcare & Pharmaceuticals |
I haven't seen anything in the last three years to alter this chart significantly.
Carliss Y. Baldwin - Capital Investment and Technological Competition
Carliss Y. Baldwin and Kim B. Clark are studying resource allocation in knowledge-based industries. Finding that traditional financial models of resource allocation do not explain the investment practices of high-tech companies, Baldwin and Clark embarked on a study of resource allocation in, and competition among, a small group of companies in the workstation industry. Specifically, they are trying to explain two anomalous characteristics of companies in this and other high-tech industries: they periodically become locked in a pattern of hyperaccelerated growth that demands substantial, repeated infusions of capital; and they span a high degree of vertical fragmentation with contracts and alliances. Baldwin and Clark are currently investigating the impact of system modularity on financial returns and the rate of technological change.
open-source: del.icio.us tag/open-source
Development
Software
design
business
complexity
modularity
large-scale
[from jaz] Infinity in a grain of sand
Where on earth does that pattern and beauty come from. Where is that contained in xn+1 = xn2 + c?
The Trillion-Dollar Vision of Dee Hock
The corporate radical who organized Visa wants to dis-organize your company.
open-source: del.icio.us tag/open-source
open-source
future
organization
visa
philosophy
economics
complexity
Enumerating a context-free language @ The dreams that stuff is made of
Luke Palmer — music, programming
Complexity-Based Pricing
In this post, prompted by Gordon's Notes on Complexity and Mobile Phone Plans, I want to talk about Complexity as a Weapon.
The term "Complexity as a Weapon" only occurs a few times on the Internet. Ten years ago, Scott Bradner wrote a column for ComputerWorld called Complexity as a Weapon. He was referring mainly to large software organizations resisting simple standards, as a tactic for achieving an advantage over smaller organizations with fewer resources. In a discussion with Russell Ackoff on Why few organizations adopt systems thinking, Jim Leemann talks about complexity as a tactic for resisting any kind of positive change. And an organization called Focus on the Global South accused oil companies of using complex accounting solely in order to reduce tax liability (Destroy and Profit, pdf).
But Gordon's Notes discusses Complexity-as-a-Weapon in the context of service pricing, where complexity is designed to prevent service consumers optimizing their service costs (so-called ninja shopping), as I indicated in my review of the Support Economy.
Excessive complexity of this kind is ultimately self-defeating: it adds to everyone's transaction costs, and erodes the value and viability of the service itself.
The term "Complexity as a Weapon" only occurs a few times on the Internet. Ten years ago, Scott Bradner wrote a column for ComputerWorld called Complexity as a Weapon. He was referring mainly to large software organizations resisting simple standards, as a tactic for achieving an advantage over smaller organizations with fewer resources. In a discussion with Russell Ackoff on Why few organizations adopt systems thinking, Jim Leemann talks about complexity as a tactic for resisting any kind of positive change. And an organization called Focus on the Global South accused oil companies of using complex accounting solely in order to reduce tax liability (Destroy and Profit, pdf).
But Gordon's Notes discusses Complexity-as-a-Weapon in the context of service pricing, where complexity is designed to prevent service consumers optimizing their service costs (so-called ninja shopping), as I indicated in my review of the Support Economy.
"Providers retaliate with an increasingly impenetrable array of extras, excesses and surcharges, which aim to recoup profit margins while making accurate price comparison near-impossible."
Excessive complexity of this kind is ultimately self-defeating: it adds to everyone's transaction costs, and erodes the value and viability of the service itself.
[from wnpxrz] In pursuit of code quality: Monitoring cyclomatic complexity
"If complexity has been shown to correlate to defects, doesn't it make sense to monitor your code base's complexity values? Andrew Glover shows you how to use simple code metrics and Java_-based tools to monitor cyclomatic complexity."
Page 1 | Next >>
