Web Services enable composition through lowest-common-denominator ubiquitous protocols.
Composite applications pull together Web services to fulfill some set of requirements. If you compile the services together (bake at 450 degrees), you'll find that the agile-controller isn't so agile.
So, all of this said... what is the Composite Application Strategy for Microsoft? All the work on Indigo was great, but where is my 'service join' facility, or my 'agile controller' - for that matter, where is my 'semantic adapter'?
From one perspective you could say that SDM represents a portion of the strategy - but it only reflects the 'service oriented bill of materials'. BizTalk? Wow - I hope not... any insight?
If you're not familiar with 'composite applications platforms', take a look at:
http://www.cordys.com
and
http://www.aboveallsoftware.com
Tuesday, July 26, 2005
Saturday, July 23, 2005
Hacktivity Level
The 'hacktivity level' is way up. Casual services, dynamic scripting and remixing are clearly the theme for 2005. JSON, POX, REST, RSS, etc. have taken hold - they've intersected with client-side contextual applications like Google Maps to create what some people would have called a composite application - you may prefer the terms remix or mash-up. Even Business Week is taking notice.
SOAP & WS-* have turned into the stiff-collared, corporate world, slow to move technologies. Once again, our passionate technology community is breaking all the rules and creating compelling applications - and I love it.
CIO - "Did you see what some hacker did with concert reservations? Can we provide our core services to the outside world? Wait - can we consume other peoples services and create our own application out of them??" - Why yes.
The World Wide Web is turning into the Service Oriented Web. The technologies will be stiff and flimsy; the artists will be straight-laced and no-laced. The intersection will be magnificent; the Web is reborn. The SOAP/WS "transactional web" will be a portion of the new SOW, perhaps a small portion. Our future will be driven by those who have the passion and desire to create it.
SOAP & WS-* have turned into the stiff-collared, corporate world, slow to move technologies. Once again, our passionate technology community is breaking all the rules and creating compelling applications - and I love it.
Hacker - 'I need that service and that other service. I need to combine them. I need a server-side aggregation engine. I need to re-serve the combined service. I wonder who will enrich/transform my service? Who cares. I need a client-side visualization mechanism. It has to have easy API's that front-end the data services. Damn this is cool. Interesting - it looks like a 'web of services'. Clients. I need contextual pivoting - Maps - Austin - Concert Halls - Concerts - Reviews - Tickets - Buy - Receipt - Calendar.'
CIO - "Did you see what some hacker did with concert reservations? Can we provide our core services to the outside world? Wait - can we consume other peoples services and create our own application out of them??" - Why yes.
The World Wide Web is turning into the Service Oriented Web. The technologies will be stiff and flimsy; the artists will be straight-laced and no-laced. The intersection will be magnificent; the Web is reborn. The SOAP/WS "transactional web" will be a portion of the new SOW, perhaps a small portion. Our future will be driven by those who have the passion and desire to create it.
Thursday, July 14, 2005
Hey Don Box,
All of us in the SOA blogosphere have appreciated your input and insight. However it has come to my attention that Microsoft isn't practicing what they're preaching. I'm hoping that you can tell me that my information is dead wrong.
I ask one simple favor. Start blogging about how Microsoft is using SOA internally. I've been told that Microsoft spends more money on SOA evangelists than they do on building SOA solutions internally.
I'll extend this challenge to every single Microsoft blogger. Don't tell me about your latest spec or library - tell me how Microsoft uses it internally. The Microsoft I.T. department should become the SOA showcase.
Respectfully Submitted,
Jeff
I ask one simple favor. Start blogging about how Microsoft is using SOA internally. I've been told that Microsoft spends more money on SOA evangelists than they do on building SOA solutions internally.
I'll extend this challenge to every single Microsoft blogger. Don't tell me about your latest spec or library - tell me how Microsoft uses it internally. The Microsoft I.T. department should become the SOA showcase.
Respectfully Submitted,
Jeff
Sunday, July 10, 2005
I, Too, Have Seen the Enemy
Charles Garry comments, "I Have Seen the Enemy and It Is Complexity". He writes,
He goes on to state:
Charles believes that Web services increases complexity. By no stretch of the imagination do I consider myself an expert in complexity, chaos, systemics or related concepts. However, I believe that the conclusion Charles reaches is incorrect.
His assumption is that we are adding new elements to a set - and as the set grows, so does the complexity of the set. His answer is to reduce the number of elements (rationalization and consolidation) and this is where we differ.
Enterprise software is going through a 'specialization' and 'externalization' movement. We are taking pieces of code that seemed unique and abstracting them into reusable concepts. We do this with design patterns, architectural patterns, domain specific languages, platforms, libraries and specialized engines. Each time we see these reusable items, we 'write them down' (or externalize them). The complexity in the system already existed; we merely found the pattern, factored out the common substrate and documented it. Externalization is a well-known mechanism for reducing complexity; you take that which was not understood and make it understood.
As we take our mountains of unintelligible 3GL code and move much of it into common infrastructure, we increase the amount of 'known' computing elements and decrease the amount of 'unknown'. This process has an odd effect. As the inventory of known elements grows so does the concern for 'having too much'. This leads to a human fear of 'large-set-complexity'. And the natural reaction is, yes - you guessed it, rationalization and consolidation. This is a human tendency whereby man attempts to diminish complexity by hiding it. We take those First Order computing elements that made our inventory list and reduce them back into 2nd order elements, thus removing them from our list. And somehow, we feel better that we defeated the enemy.
Specialization of vocabularies, models and elements is a natural progression of every science. However, specialization must be followed with abstractions, taxonomies and containment. In essence, we must not hide our new found computational elements, rather we must manage them.
Web services are an additional element to our computing infrastructure. From one vantage you can claim that they are just another element to the set increasing the complexity. However, Web services will help to reduce systems complexity by adding a new abstraction over our computing environment. Although the total number of elements increases, we find ourselves commoditizing those lower in the stack and working with those that are closer to the business value.
The enemy of SOA isn't complexity; it is a lack of understanding. We must not retreat from our sophisticated computing infrastructure. Instead we must use cost effective means to manage the piece-parts, identify the abstractions, create common groupings and externalize the system.
"Web services is yet another example of potential complexity headed your way." ... "I have perused a number of books on the subject, but the one thing I never see discussed is how one makes a virtual application highly available. What are the implications for backup and recovery of data? How do we manage security permissions and authorizations? Clearly, with the added flexibility, we have also created a new set of obstacles to overcome."
He goes on to state:
I suspect we will continue to see a growing trend towards infrastructure rationalization (fewer kinds of things) and consolidation (fewer numbers of things) as a means to reduce complexity. This trend is both useful and necessary if we have any hope of utilizing some of these new computing paradigms.
Charles believes that Web services increases complexity. By no stretch of the imagination do I consider myself an expert in complexity, chaos, systemics or related concepts. However, I believe that the conclusion Charles reaches is incorrect.
His assumption is that we are adding new elements to a set - and as the set grows, so does the complexity of the set. His answer is to reduce the number of elements (rationalization and consolidation) and this is where we differ.
Enterprise software is going through a 'specialization' and 'externalization' movement. We are taking pieces of code that seemed unique and abstracting them into reusable concepts. We do this with design patterns, architectural patterns, domain specific languages, platforms, libraries and specialized engines. Each time we see these reusable items, we 'write them down' (or externalize them). The complexity in the system already existed; we merely found the pattern, factored out the common substrate and documented it. Externalization is a well-known mechanism for reducing complexity; you take that which was not understood and make it understood.
As we take our mountains of unintelligible 3GL code and move much of it into common infrastructure, we increase the amount of 'known' computing elements and decrease the amount of 'unknown'. This process has an odd effect. As the inventory of known elements grows so does the concern for 'having too much'. This leads to a human fear of 'large-set-complexity'. And the natural reaction is, yes - you guessed it, rationalization and consolidation. This is a human tendency whereby man attempts to diminish complexity by hiding it. We take those First Order computing elements that made our inventory list and reduce them back into 2nd order elements, thus removing them from our list. And somehow, we feel better that we defeated the enemy.
Specialization of vocabularies, models and elements is a natural progression of every science. However, specialization must be followed with abstractions, taxonomies and containment. In essence, we must not hide our new found computational elements, rather we must manage them.
Web services are an additional element to our computing infrastructure. From one vantage you can claim that they are just another element to the set increasing the complexity. However, Web services will help to reduce systems complexity by adding a new abstraction over our computing environment. Although the total number of elements increases, we find ourselves commoditizing those lower in the stack and working with those that are closer to the business value.
The enemy of SOA isn't complexity; it is a lack of understanding. We must not retreat from our sophisticated computing infrastructure. Instead we must use cost effective means to manage the piece-parts, identify the abstractions, create common groupings and externalize the system.
Saturday, July 09, 2005
Crush My Head Like an Acorn
Sean McGrath has suggested that the Reed's Proposition may be closer than Metcalfe's Law in describing a theoretical upper limit value function on a Servcie Network.
For those of you who haven't had the pleasure of meeting Sean, his physical presence reminds me of the "boulder thrower" on Braveheart:
I firmly believe that Sean could crush my head like an acorn with his bare hands. Hence, I'll be careful to disagree with him.
Acorns and noggins aside, as usual Sean makes a great point. Metcalfe's law is an over-simplification of a complex formula. In my humble opinion, so is Reed's.
My goal is simple - I want the enterprise to begin looking at their services as a network and determining the value function that works for them. Today, virtually no formulas are applied.
It is true that some services will provide more value than others. And some business processes are fundamentally more important to competitive advantage than others. Services that support key processes will provide greater value. We will also see that 'service gaps' will destroy the value of 'process networks', suggesting that some services only have value when bundled with other complementary services in the same value chain.
Value chains are created around: customers, suppliers, products, employees, etc. We create networks that link these entities using various levels of constraints. Those links which require minimal constraints are usually deployed first and are the most free-flowing and collaborative in nature. From a computing perspective these entities will be joined via well known networks including WWW and RSS. The value of low-constraint, high collaboration networks is well known.
As we increase the level of constraints and diminish the ease of creating self-forming networks due to semantic mismatches, protocol impedance or the mandate to fulfill non-functional requirements, we find ourselves creating services with a lower ROI. This isn't because the "R" (return) has changed; it is because the "I" (investment) has changed.
Enterprise Service Networks will not produce an adequate ROI if they are not able to reduce the 'service drag', lowering the investment. That is, it is the burden of the enterprise to employ 'service oriented infrastructure' that facilitates rapid service creation and composition by removing the aforementioned obstacles. In essence, the value function must look forward in time, forecasting a future value of the network, less the 'drag' related to adding clients and services. This is what I call the AOL Argument; fundamentally the Web created a more fertile environment for adding content to a network than did AOL.
Corporations use valuations that are forward looking vehicles (DCF, EVA, etc.) I would argue that the value of the network is less of a snapshot in time but rather a forward looking forecast based on the potential growth of the network as it directly relates to the value chain of an organization. I view the Metcalfe/Reed concepts as an easy way to introduce I.T. personnel to network valuations. However, due to their inability to capture forward looking results and correlate node-to-value concepts, they both remain inadequate at best.
Please don't crush my head like an acorn ;-)
For those of you who haven't had the pleasure of meeting Sean, his physical presence reminds me of the "boulder thrower" on Braveheart:
I firmly believe that Sean could crush my head like an acorn with his bare hands. Hence, I'll be careful to disagree with him.
Acorns and noggins aside, as usual Sean makes a great point. Metcalfe's law is an over-simplification of a complex formula. In my humble opinion, so is Reed's.
My goal is simple - I want the enterprise to begin looking at their services as a network and determining the value function that works for them. Today, virtually no formulas are applied.
It is true that some services will provide more value than others. And some business processes are fundamentally more important to competitive advantage than others. Services that support key processes will provide greater value. We will also see that 'service gaps' will destroy the value of 'process networks', suggesting that some services only have value when bundled with other complementary services in the same value chain.
Value chains are created around: customers, suppliers, products, employees, etc. We create networks that link these entities using various levels of constraints. Those links which require minimal constraints are usually deployed first and are the most free-flowing and collaborative in nature. From a computing perspective these entities will be joined via well known networks including WWW and RSS. The value of low-constraint, high collaboration networks is well known.
As we increase the level of constraints and diminish the ease of creating self-forming networks due to semantic mismatches, protocol impedance or the mandate to fulfill non-functional requirements, we find ourselves creating services with a lower ROI. This isn't because the "R" (return) has changed; it is because the "I" (investment) has changed.
Enterprise Service Networks will not produce an adequate ROI if they are not able to reduce the 'service drag', lowering the investment. That is, it is the burden of the enterprise to employ 'service oriented infrastructure' that facilitates rapid service creation and composition by removing the aforementioned obstacles. In essence, the value function must look forward in time, forecasting a future value of the network, less the 'drag' related to adding clients and services. This is what I call the AOL Argument; fundamentally the Web created a more fertile environment for adding content to a network than did AOL.
Corporations use valuations that are forward looking vehicles (DCF, EVA, etc.) I would argue that the value of the network is less of a snapshot in time but rather a forward looking forecast based on the potential growth of the network as it directly relates to the value chain of an organization. I view the Metcalfe/Reed concepts as an easy way to introduce I.T. personnel to network valuations. However, due to their inability to capture forward looking results and correlate node-to-value concepts, they both remain inadequate at best.
Please don't crush my head like an acorn ;-)
Friday, July 08, 2005
The Value of the Service Network
Just a quick reminder...
We aren't just building Web services.
We aren't just creating an SOA.
We are building a network of business services.
We must also remember that it takes MORE work to create VALUABLE services.
We aren't just building Web services.
We aren't just creating an SOA.
We are building a network of business services.
We must also remember that it takes MORE work to create VALUABLE services.
Sunday, July 03, 2005
Sun's Big Year - 2186
Based on historical performance of SeeBeyond (income statement), and including new synergies (sales force, engineering), I estimate that Sun should break even on their $387,000,000 cash investment in the year 2186. I realize that it is tough to wait 181 years for the ROI to kick in - but I'm sure Scott (and his great grandchildren) will be patient - as will Wall Street.
I wish Sun the best of luck getting JBI adopted.
I should mention to the M&A crew at Sun - - I heard a hot rumor! A COBOL company is up for sale!! Time for JSR 38,940 - JCOBOL! You'll make BILLIONS!
I wish Sun the best of luck getting JBI adopted.
I should mention to the M&A crew at Sun - - I heard a hot rumor! A COBOL company is up for sale!! Time for JSR 38,940 - JCOBOL! You'll make BILLIONS!
The Service Network - July 2005
Our July edition of The Service Network is available.
And yes, the favorite line seems to be:
And yes, the favorite line seems to be:
"SOMA (Service Oriented Modeling and Architecture) –Vaporware or IBM Global Services with a copy of Visio?"
Subscribe to:
Posts (Atom)