Jeff Tonkel of Infravio recently pointed out the importance of the registry in a service oriented architecture. I'd like to second that thought. While I'm at it, I'll go so far as to state my opinion on who is leading in the space.
For starters, you have to look at BlueTitan. These guys get one real simple fact - you don't implement a registry for the sake of having a registry. Many vendors wrote a registry and encouraged their customers to dump crap in it. Bad idea. BlueTitan took the other approach - they started with the 'ilities' and worked backwards into the metadata that needed to be captured to manage a service network. Their registry is designed to capture only 'usable' metadata (actionable information); don't store anything that can't be used. Also they focused on the needs of enterprise grade service networks, the people with the really hard problems. I'm thrilled to see BlueTitan recognize that services are often just 'bumps on the network', that policies are 'service oriented aspects' and that the metadata and registry are the heart of making it functionally scalable. Most networks grow exponentially for some period of time; BlueTitan makes it possible to manage high growth networks on a linear cost scale.
After BlueTitan, you have to look at Systinet. Although these guys started with a strong UDDI slant, I believe they not only understand the limitations of UDDI, but are well on their way to overcoming the issues. I anticipate that Systinet will also have strong 'developer-side' integration into the registry (think reusable assets).
The registry is quickly turning into the 'metadata warehouse' - it is the point where a 'metadata driven architecture' and the 'service oriented architecture' merge. Architects are slowly figuring out that an important aspect of the SOA is the ability to factor the ilities out of applications. The registry is key to facilitating this movement.
Saturday, October 30, 2004
Friday, October 22, 2004
The AToM Splits Definition
The AToM, Anne Thomas Manes, took the time to mark up some definitions of SOA. I love it. Four things I'd change:
1. Services don't have to be 'autonomous'
2. Services don't have to be used for 'business'
3. In many cases services shouldn't be designed for 'reuse'
4. In many cases services won't be 'discovered'
Thus, try not to use those four words in the definition.
Posted on the soa news group...
===============================================
SearchWebServices asked this group of people to provide 50 word descriptions
of SOA. It's very hard to describe SOA in just 50 words (and obviously some
folks ignored the 50 word limit). You simply can't describe the tenets of
SOA so succinctly. Burton Group recently published a 22 page report
describing SOA, which I think does a much better job than any of these short
descriptions. I could easily write an entire book on the topic.
In my description, I endeavored to convey two of what I consider to be the
three major tenets of SOA: application factoring and abstraction, although I
was not able to convey the multiple aspects of these two tenets. I was also
not able to convey the third tenet: the requirement for standard protocols
for description, discovery, and communication.
Please see my comments below bracketed by ::atm::::/atm::.
-----Original Message-----
From: Gervas Douglas [mailto:gervasdouglas@yahoo.co.uk]
Sent: Thursday, October 21, 2004 12:53 PM
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] Re: Definition of SOA
Here are some definitions provided by SearchWebServices:
::::-------------------------------------------------------------------
-------------
"SOA is a framework enabling application functionality to be
provided, discovered and consumed as re-usable Web Services sets.
While Web Services do not equal SOA, it's one of the enabling
standards. SOA abstracts complexity and implementation details,
making it an ideal architectural mindset to leverage functionality
trapped within mainframe/midrange systems."
Scott Rosenbloom is chief strategist with WRQ Inc.
::atm:: SOA is an architecture -- not a framework. It is a style of design --
not a tool. On the other hand, "web services" is a framework -- a set of
tools (middleware) to help you implement applications and systems that
adhere to SOA design principles. (Although note that building applications
using the web services framework does not guarantee SOA.) SOA requires
standard protocols for description, discovery, and communication. The web
services framework standards define these standard protocols --
XMLSchema/WSDL, UDDI, and SOAP respectively, at a fundamental level,
although these core standards are not sufficient to support all SOA
requirements (secure, reliable, transacted applications supporting diverse
message exchange patterns) -- hence the ongoing effort to develop the WS-*
standards.
From my perspective, the best way to describe SOA is in terms of design
principles. Abstraction is one of the core tenets of SOA -- abstraction
between the interface and the implementation, and abstraction between
infrastructure and business logic. WSDL facilitates the first, and SOAP
facilitates the second. Another core tenet is proper application
functionality factoring. What granularity should a service have to best
enable reusability? I think this is the most challenging aspect of SOA. My
rule of thumb is that a service should represent a business task. But it's
hard to quantify this rule. ::/atm::
---------------------------------------------------------------------
-----------
"Secure, integrated delivery of IT solutions meeting business
requirements. Solutions must implement, optimize and guide business
process execution by combining the functionality of separate,
discreet, reusable services. SOA moves away from complex application
development, promoting a focus on standardizing interfaces between
atomic service components with centralized management and
distributed implementation."
Dave Morris, I.T. Security Lead TransAlta Corp.
::atm:: For the most part, I don't think this definition helps explain what
SOA means, but I like that fact that he associates SOA with "centralized
management and distributed implementation". As I said in my response to the
first definition, one of the core tenets of SOA is the requirement for
abstraction between infrastructure and business logic. Via the separation of
the SOAP Header from the SOAP Body, and via the requirements of the SOAP
processing model, SOAP enables the clean separation of infrastructure from
business logic. It permits developers to externalize most, if not all,
infrastructure functionality to the middleware. This feature enables
centralized management of the distributed implementation. ::/atm::
---------------------------------------------------------------------
-----------
"The SOA models the business as a collection of self-contained
services that are available across the enterprise that can be evoked
through standard protocols both internally and externally."
Dave McComb, president, Semantic Arts
::atm:: An accurate description, but it doesn't give you any real information
to work with. ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture is nothing but business oriented
architecture, which allows the flexibility of business applications,
to become independent but collaborative, while providing their
services. The applications under this architecture are both 'client'
and 'server' at the same time with freely available services."
Satheesan Kunnel, USWWI
::atm:: While it's definitely a brilliant idea to align IT with business, I
don't think this definition helps you figure out how to do so. ::/atm::
---------------------------------------------------------------------
-----------
"A service oriented architecture is an approach to design and
integrate software in a modular method where each module is
precisely a 'loosely coupled service' that is accessible over a
network and has the capability of being dynamically integrated with
other services at run time. A service must present a standard
Interface (be it WSDL today) for its functionality and invocation
methods while the real implementation of the service is not a
concern of an SOA."
Rajesh Dawar
::atm:: I like this definition, although I'd like to see a little more
definition of what a "precisely" loosely coupled service is. From my
perspective, the standard communication protocol has equal importance to the
standard description protocol, although this definition obviously gives more
weight to the description language. I also view XML Schema as equal weight
to WSDL. Again note that SOA does not require XML Schema, WSDL, and SOAP
specifically, but it does require that applications rely on a set of
standard protocols. When using web services to implement SOA, those standard
protocols are XML Schema, WSDL, and SOAP. ::/atm::
---------------------------------------------------------------------
-----------
"Services provide something of value to those who know how to
request and consume them, without having to know how to produce that
value. SOA is an approach to building software applications as
collections of autonomous services that interact without regard to
each other's platform, data structures, or internal algorithms."
Michael Champion, R&D specialist, Software AG
::atm:: Excellent short description! ::/atm::
---------------------------------------------------------------------
-----------
"A pattern of design, development, deployment, and management of (a)
applications and (b) software infrastructure and frameworks in
which:
Applications are organized into business units of work (services)
that are (typically) network accessible
Service interface definitions are first-class development artifacts
Quality of service (QoS) characteristics (security, transactions,
performance, etc.) are explicitly identified at design time
Software infrastructure takes active responsibility for managing QoS
and enforcing policy for service access and execution
Services and their metadata are cataloged in a repository
Protocols and structures within the architecture are, optionally,
based on industry standards (e.g., the emerging SOAP stack of
standards)
Randy Heffner, vice president, Forrester Research Inc.
::atm:: I have to question Randy's requirement that QoS characteristics must
be explicitly identified at design time. Perhaps he's talking about
composite application design time? -- the time when you are assembling
services? But even here I disagree. I contend that one of the most brilliant
features of SOAP and the web services framework is that it permits you to
externalize QoS functionality from the application so that it does not need
to be defined at service design time. Instead these requirements can and
should be specified at configuration time. QoS functionality can be
externalized from the application, specified via policies, and enforced
through the middleware. This is a required feature for reusability. The
security, reliability, transaction, and performance requirements of a
service may vary depending on how it is used in a particular composite
application or based on the specific client invoking the service. Rather
than hard-coding this complex functionality in the application, you can
configure the functionality using deployment and configuration wizards --
just tick the box to add security and reliability functionality. This
configuration process should generate a policy description (e.g.,
WS-Policy), which becomes part of the overall metadata/description contract
of the service (consisting of XML Schema, WSDL, WS-Policy, and potentially
other description languages).
Almost no one is using WS-Policy today, and I view it as one of the most
critical holes in the current web services framework. ::/atm::
---------------------------------------------------------------------
-----------
"SOA is a style of design that strives to enable easy integration
and flexible applications. In SOA, application functionality is
designed as shared reusable services. A service is a piece of
application functionality that exposes its functionality through an
abstract interface, which hides the inner workings of the service
implementation."
Anne Thomas Manes, analyst, Burton Group
---------------------------------------------------------------------
-----------
"An SOA is an enterprise-scale architecture (typically spanning
multiple applications within an enterprise or across multiple
enterprises) where the primary structuring element is a service (as
opposed to modules, systems, applications or components).
A service is a set of related business functions that are interacted
with locally or remotely using a message-passing/document-oriented
communication style. A service is composed of (1) a (functional)
service interface and (2) a service implementation that implements
one or more service interfaces and adheres to a certain set of (non-
functional) capabilities. Specific services are defined in terms of
the transport/application/messaging protocol, not in terms of a
specific programming model.
An SOA will typically include technical services to manage metadata
about service interfaces and implementations, service providers and
service consumers; and services for managing and enforcing policies,
access control, security features, and transactions, although all of
these are optional within any specific SOA instance."
Stefan Tilkov, CEO, innoQ
::atm:: Excellent description! (although Stefan obviously exceeded the 50 word
maximum) ::/atm::
---------------------------------------------------------------------
-----------
"Service-oriented architecture is an architectural discipline that
centers on the notion that IT assets are described and exposed as
Services. These Services can then be composed in a loosely-coupled
fashion into higher-level business processes, which providing
business agility in the face of IT heterogeneity."
Ronald Schmelzer, analyst, ZapThink LLC
::atm:: Excellent description! ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture (SOA) is an approach to the
development of loosely coupled, protocol-independent distributed
applications composed from well-defined, self-contained software
resources accessible as Services across the extended enterprise in a
standardized way, enhancing re-usability and interoperability."
Ankur Gupta, marketing manager, Fiorano Software Inc.
::atm:: Good description, although hard to parse. ::/atm::
1. Services don't have to be 'autonomous'
2. Services don't have to be used for 'business'
3. In many cases services shouldn't be designed for 'reuse'
4. In many cases services won't be 'discovered'
Thus, try not to use those four words in the definition.
Posted on the soa news group...
===============================================
SearchWebServices asked this group of people to provide 50 word descriptions
of SOA. It's very hard to describe SOA in just 50 words (and obviously some
folks ignored the 50 word limit). You simply can't describe the tenets of
SOA so succinctly. Burton Group recently published a 22 page report
describing SOA, which I think does a much better job than any of these short
descriptions. I could easily write an entire book on the topic.
In my description, I endeavored to convey two of what I consider to be the
three major tenets of SOA: application factoring and abstraction, although I
was not able to convey the multiple aspects of these two tenets. I was also
not able to convey the third tenet: the requirement for standard protocols
for description, discovery, and communication.
Please see my comments below bracketed by ::atm::::/atm::.
-----Original Message-----
From: Gervas Douglas [mailto:gervasdouglas@yahoo.co.uk]
Sent: Thursday, October 21, 2004 12:53 PM
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] Re: Definition of SOA
Here are some definitions provided by SearchWebServices:
::::-------------------------------------------------------------------
-------------
"SOA is a framework enabling application functionality to be
provided, discovered and consumed as re-usable Web Services sets.
While Web Services do not equal SOA, it's one of the enabling
standards. SOA abstracts complexity and implementation details,
making it an ideal architectural mindset to leverage functionality
trapped within mainframe/midrange systems."
Scott Rosenbloom is chief strategist with WRQ Inc.
::atm:: SOA is an architecture -- not a framework. It is a style of design --
not a tool. On the other hand, "web services" is a framework -- a set of
tools (middleware) to help you implement applications and systems that
adhere to SOA design principles. (Although note that building applications
using the web services framework does not guarantee SOA.) SOA requires
standard protocols for description, discovery, and communication. The web
services framework standards define these standard protocols --
XMLSchema/WSDL, UDDI, and SOAP respectively, at a fundamental level,
although these core standards are not sufficient to support all SOA
requirements (secure, reliable, transacted applications supporting diverse
message exchange patterns) -- hence the ongoing effort to develop the WS-*
standards.
From my perspective, the best way to describe SOA is in terms of design
principles. Abstraction is one of the core tenets of SOA -- abstraction
between the interface and the implementation, and abstraction between
infrastructure and business logic. WSDL facilitates the first, and SOAP
facilitates the second. Another core tenet is proper application
functionality factoring. What granularity should a service have to best
enable reusability? I think this is the most challenging aspect of SOA. My
rule of thumb is that a service should represent a business task. But it's
hard to quantify this rule. ::/atm::
---------------------------------------------------------------------
-----------
"Secure, integrated delivery of IT solutions meeting business
requirements. Solutions must implement, optimize and guide business
process execution by combining the functionality of separate,
discreet, reusable services. SOA moves away from complex application
development, promoting a focus on standardizing interfaces between
atomic service components with centralized management and
distributed implementation."
Dave Morris, I.T. Security Lead TransAlta Corp.
::atm:: For the most part, I don't think this definition helps explain what
SOA means, but I like that fact that he associates SOA with "centralized
management and distributed implementation". As I said in my response to the
first definition, one of the core tenets of SOA is the requirement for
abstraction between infrastructure and business logic. Via the separation of
the SOAP Header from the SOAP Body, and via the requirements of the SOAP
processing model, SOAP enables the clean separation of infrastructure from
business logic. It permits developers to externalize most, if not all,
infrastructure functionality to the middleware. This feature enables
centralized management of the distributed implementation. ::/atm::
---------------------------------------------------------------------
-----------
"The SOA models the business as a collection of self-contained
services that are available across the enterprise that can be evoked
through standard protocols both internally and externally."
Dave McComb, president, Semantic Arts
::atm:: An accurate description, but it doesn't give you any real information
to work with. ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture is nothing but business oriented
architecture, which allows the flexibility of business applications,
to become independent but collaborative, while providing their
services. The applications under this architecture are both 'client'
and 'server' at the same time with freely available services."
Satheesan Kunnel, USWWI
::atm:: While it's definitely a brilliant idea to align IT with business, I
don't think this definition helps you figure out how to do so. ::/atm::
---------------------------------------------------------------------
-----------
"A service oriented architecture is an approach to design and
integrate software in a modular method where each module is
precisely a 'loosely coupled service' that is accessible over a
network and has the capability of being dynamically integrated with
other services at run time. A service must present a standard
Interface (be it WSDL today) for its functionality and invocation
methods while the real implementation of the service is not a
concern of an SOA."
Rajesh Dawar
::atm:: I like this definition, although I'd like to see a little more
definition of what a "precisely" loosely coupled service is. From my
perspective, the standard communication protocol has equal importance to the
standard description protocol, although this definition obviously gives more
weight to the description language. I also view XML Schema as equal weight
to WSDL. Again note that SOA does not require XML Schema, WSDL, and SOAP
specifically, but it does require that applications rely on a set of
standard protocols. When using web services to implement SOA, those standard
protocols are XML Schema, WSDL, and SOAP. ::/atm::
---------------------------------------------------------------------
-----------
"Services provide something of value to those who know how to
request and consume them, without having to know how to produce that
value. SOA is an approach to building software applications as
collections of autonomous services that interact without regard to
each other's platform, data structures, or internal algorithms."
Michael Champion, R&D specialist, Software AG
::atm:: Excellent short description! ::/atm::
---------------------------------------------------------------------
-----------
"A pattern of design, development, deployment, and management of (a)
applications and (b) software infrastructure and frameworks in
which:
Applications are organized into business units of work (services)
that are (typically) network accessible
Service interface definitions are first-class development artifacts
Quality of service (QoS) characteristics (security, transactions,
performance, etc.) are explicitly identified at design time
Software infrastructure takes active responsibility for managing QoS
and enforcing policy for service access and execution
Services and their metadata are cataloged in a repository
Protocols and structures within the architecture are, optionally,
based on industry standards (e.g., the emerging SOAP stack of
standards)
Randy Heffner, vice president, Forrester Research Inc.
::atm:: I have to question Randy's requirement that QoS characteristics must
be explicitly identified at design time. Perhaps he's talking about
composite application design time? -- the time when you are assembling
services? But even here I disagree. I contend that one of the most brilliant
features of SOAP and the web services framework is that it permits you to
externalize QoS functionality from the application so that it does not need
to be defined at service design time. Instead these requirements can and
should be specified at configuration time. QoS functionality can be
externalized from the application, specified via policies, and enforced
through the middleware. This is a required feature for reusability. The
security, reliability, transaction, and performance requirements of a
service may vary depending on how it is used in a particular composite
application or based on the specific client invoking the service. Rather
than hard-coding this complex functionality in the application, you can
configure the functionality using deployment and configuration wizards --
just tick the box to add security and reliability functionality. This
configuration process should generate a policy description (e.g.,
WS-Policy), which becomes part of the overall metadata/description contract
of the service (consisting of XML Schema, WSDL, WS-Policy, and potentially
other description languages).
Almost no one is using WS-Policy today, and I view it as one of the most
critical holes in the current web services framework. ::/atm::
---------------------------------------------------------------------
-----------
"SOA is a style of design that strives to enable easy integration
and flexible applications. In SOA, application functionality is
designed as shared reusable services. A service is a piece of
application functionality that exposes its functionality through an
abstract interface, which hides the inner workings of the service
implementation."
Anne Thomas Manes, analyst, Burton Group
---------------------------------------------------------------------
-----------
"An SOA is an enterprise-scale architecture (typically spanning
multiple applications within an enterprise or across multiple
enterprises) where the primary structuring element is a service (as
opposed to modules, systems, applications or components).
A service is a set of related business functions that are interacted
with locally or remotely using a message-passing/document-oriented
communication style. A service is composed of (1) a (functional)
service interface and (2) a service implementation that implements
one or more service interfaces and adheres to a certain set of (non-
functional) capabilities. Specific services are defined in terms of
the transport/application/messaging protocol, not in terms of a
specific programming model.
An SOA will typically include technical services to manage metadata
about service interfaces and implementations, service providers and
service consumers; and services for managing and enforcing policies,
access control, security features, and transactions, although all of
these are optional within any specific SOA instance."
Stefan Tilkov, CEO, innoQ
::atm:: Excellent description! (although Stefan obviously exceeded the 50 word
maximum) ::/atm::
---------------------------------------------------------------------
-----------
"Service-oriented architecture is an architectural discipline that
centers on the notion that IT assets are described and exposed as
Services. These Services can then be composed in a loosely-coupled
fashion into higher-level business processes, which providing
business agility in the face of IT heterogeneity."
Ronald Schmelzer, analyst, ZapThink LLC
::atm:: Excellent description! ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture (SOA) is an approach to the
development of loosely coupled, protocol-independent distributed
applications composed from well-defined, self-contained software
resources accessible as Services across the extended enterprise in a
standardized way, enhancing re-usability and interoperability."
Ankur Gupta, marketing manager, Fiorano Software Inc.
::atm:: Good description, although hard to parse. ::/atm::
Wednesday, October 20, 2004
The State of SOA - Quick Summary
Here's a quick summary of what I've seen recently in the SOA space:
1. Styles
A. HTTP / XML-RPC / AddToCart *** xml over http
B. HTTP / Post / Cart/Add *** REST Rules!!
C. AnyTransport / SOAP WS-Hdr / AddToCart *** SOAP Rules!!
D. AnyTransport / SOAP WS-Hdr / POST / Cart *** SOAP with WS-Transfer Rules!!
E. All of the above (we'll use a bump in the network to translate between them)
2. BPEL
A. If you can't put J in front of it than it doesn't exist (J-BPEL). You "J" people are so myopic. No, you "X" people insist on doing things the hard way.
B. "When I say we support BPEL, what I mean is that we support X/Lang."
C. "So, the really powerful part about BPEL is Abstract Processes... What??? Is that why none of the vendors did an implementation???"
3. Vendors
A. Our CTO quit and then the team working on the ESB quit; other than that we're on schedule.
B. Startups: We have a better product!! So what - we have customers, and have already hit 10 million in revenue - go suck an egg.
C. Oh shit, this web service thing is for real. Let's go acquire someone with our devalued stock.
4. Analysts
A. ZapThink said "blah blah blah"... A recent report from ZapThink stated, "blah blah blah" and the market size is going to be "blah blah blah".
B. All others said, " ".
5. Consultants
A. "Yippee!!!"
B. "If we keep changing the specs, perhaps the offshore people won't be able to keep up!"
6. Offshore People
A. "Yippee!!"
B. "If they keep changing the specs, there is no way the customer can afford to keep using the onshore guys!"
7. Grids
A. Who cares about service oriented; it is about 'resource oriented'.
B. IBM: "A grid is a device whereby our consultants bill you on a regular basis; hence the billing is - on demand."
8. Fortune 500
A. "We're going to have a meeting to discus our SO [fill in blank]."
B. "The budget around our SO [fill in blank] looks good for 2005.
C. "Let's tell our big vendors that lost all their people to acquire some of these little guys, then convince the offshore contractors to team up with onshore consultants while partnering with the merged ISV's; I'm sure that will work out..."
All good fun.
1. Styles
A. HTTP / XML-RPC / AddToCart *** xml over http
B. HTTP / Post / Cart/Add *** REST Rules!!
C. AnyTransport / SOAP WS-Hdr / AddToCart *** SOAP Rules!!
D. AnyTransport / SOAP WS-Hdr / POST / Cart *** SOAP with WS-Transfer Rules!!
E. All of the above (we'll use a bump in the network to translate between them)
2. BPEL
A. If you can't put J in front of it than it doesn't exist (J-BPEL). You "J" people are so myopic. No, you "X" people insist on doing things the hard way.
B. "When I say we support BPEL, what I mean is that we support X/Lang."
C. "So, the really powerful part about BPEL is Abstract Processes... What??? Is that why none of the vendors did an implementation???"
3. Vendors
A. Our CTO quit and then the team working on the ESB quit; other than that we're on schedule.
B. Startups: We have a better product!! So what - we have customers, and have already hit 10 million in revenue - go suck an egg.
C. Oh shit, this web service thing is for real. Let's go acquire someone with our devalued stock.
4. Analysts
A. ZapThink said "blah blah blah"... A recent report from ZapThink stated, "blah blah blah" and the market size is going to be "blah blah blah".
B. All others said, " ".
5. Consultants
A. "Yippee!!!"
B. "If we keep changing the specs, perhaps the offshore people won't be able to keep up!"
6. Offshore People
A. "Yippee!!"
B. "If they keep changing the specs, there is no way the customer can afford to keep using the onshore guys!"
7. Grids
A. Who cares about service oriented; it is about 'resource oriented'.
B. IBM: "A grid is a device whereby our consultants bill you on a regular basis; hence the billing is - on demand."
8. Fortune 500
A. "We're going to have a meeting to discus our SO [fill in blank]."
B. "The budget around our SO [fill in blank] looks good for 2005.
C. "Let's tell our big vendors that lost all their people to acquire some of these little guys, then convince the offshore contractors to team up with onshore consultants while partnering with the merged ISV's; I'm sure that will work out..."
All good fun.
Sunday, October 17, 2004
What scares you?
Does this Burger King commercial scare you?
It should - it's freaky!!!
Well - this is why people like web services... you see, that Big ugly king is the VENDOR. And that guy that is scared shitless - that is you. So you're wondering why the BIG PLASTIC vendor is in bed with you... right?
People are using web services to decouple them from the BIG PLASTIC guys so that they don't have to wake up with them in the morning. Go ahead, put a little distance between you and the KING. :-)
Wake up with the King?
It should - it's freaky!!!
Well - this is why people like web services... you see, that Big ugly king is the VENDOR. And that guy that is scared shitless - that is you. So you're wondering why the BIG PLASTIC vendor is in bed with you... right?
People are using web services to decouple them from the BIG PLASTIC guys so that they don't have to wake up with them in the morning. Go ahead, put a little distance between you and the KING. :-)
Wake up with the King?
Monday, October 11, 2004
New Office
Momentum has launched a new Enterprise Architecture practice. This group will also be responsible for all of the Service Oriented offerings (service network design, service adapter for legacy, realtime SO-eventing, management, etc.) It will also be working with many other architectural concerns (metadata, business process, I.T. governance, etc.)
The new practice will be based out of Reston, VA and will service clients globally. With this change, I have also move to the D.C. area. The continued growth of service oriented environments is keeping us very busy. More to come soon.
The new practice will be based out of Reston, VA and will service clients globally. With this change, I have also move to the D.C. area. The continued growth of service oriented environments is keeping us very busy. More to come soon.
Sunday, September 26, 2004
WS-MetaDataExchange and WS-Transfer
WS-Mex, also known as WS-MetadataExhange, was updated this month.
However, in an odd move the spec does not reflect the WS-Transfer udpates:
Am I missing something? I thought this was the entire point of WS-Transfer? Don't get me wrong, I still think it is absolutely hysterical that the 'Metadata' spec is mostly hard-coded and doesn't use metadata!
I've been thinking about replacing the WS-MetadataExchange spec with my own. Here it goes:
SOS-GetWSDL
1. Append "?WSDL" to the end of a call to a valid port.
2. Expect a WSDL to be returned.
3. The end.
However, in an odd move the spec does not reflect the WS-Transfer udpates:
Am I missing something? I thought this was the entire point of WS-Transfer? Don't get me wrong, I still think it is absolutely hysterical that the 'Metadata' spec is mostly hard-coded and doesn't use metadata!
I've been thinking about replacing the WS-MetadataExchange spec with my own. Here it goes:
SOS-GetWSDL
1. Append "?WSDL" to the end of a call to a valid port.
2. Expect a WSDL to be returned.
3. The end.
Sunday, September 19, 2004
On WS-Opposition
Tim Bray, who has spent the last several months crapping on the WS-* stack has agreed to shut up or put up. Thank God.
If Tim and team are able to create something better than the Service Oriented Standards (S.O.S.), then I'm the first one on board. I'd love to see Sun get active. Their pissing and moaning that they weren't invited to the party is just too old. So, here are my recommendations to S.O.S. V-2:
1. Start with a vocabulary. Write down the words you will need. Don't write them in XML - write them in English (or other non-XML markup).
2. Publish your vocabulary in the simplest manner possible.
3. Ask smart people if the words and domains are correct.
4. Compare the list to existing vocabularies (J2EE, .Net, etc.); identify the delta.
5. Apply the 80/20 rule to the words, cutting as many as possible.
6. Create a constraint based architecture. Never say "You MAY", only "YOU SHALL NOT".
7. Create profiles of constraint architectures (SMB, Enterprise, etc.)
8. Publish the candidate architectures along with the vocabularies.
9. Wait for people to crap on S.O.S. V-2; they will.
10. Defend your ideas, learn from the debate and prepare for V-3.
Good Luck. Jeff
If Tim and team are able to create something better than the Service Oriented Standards (S.O.S.), then I'm the first one on board. I'd love to see Sun get active. Their pissing and moaning that they weren't invited to the party is just too old. So, here are my recommendations to S.O.S. V-2:
1. Start with a vocabulary. Write down the words you will need. Don't write them in XML - write them in English (or other non-XML markup).
2. Publish your vocabulary in the simplest manner possible.
3. Ask smart people if the words and domains are correct.
4. Compare the list to existing vocabularies (J2EE, .Net, etc.); identify the delta.
5. Apply the 80/20 rule to the words, cutting as many as possible.
6. Create a constraint based architecture. Never say "You MAY", only "YOU SHALL NOT".
7. Create profiles of constraint architectures (SMB, Enterprise, etc.)
8. Publish the candidate architectures along with the vocabularies.
9. Wait for people to crap on S.O.S. V-2; they will.
10. Defend your ideas, learn from the debate and prepare for V-3.
Good Luck. Jeff
Friday, September 17, 2004
WS-CaveMan
I invented a new game for web service engineers called Cave Man. Here are the rules:
1. The game lasts for an hour.
2. When speaking to each other, all engineers are only allowed to use the following verbs: GET, PUT, DELETE and CREATE.
3. All predicates must be spoken in Latin or a language other than your native tongue.
4. Nouns and adjectives may be used but only if they have been written on a common whiteboard first.
Ok, I’m only joking – but you do realize that this is the game the web service engineers are being told to play with business systems.
What do I think of WS-Transfer? Easy, we have now created a vocabulary of four common words. At this pace, we should catch up to the pre-historic cave man in about 20-25 more years.
Don Box makes an interesting comment. He basically states that using four verbs can be dangerous. And I agree. However, I am of the opinion that the WS-* spec teams are doing a severe disservice to the community by releasing these specifications without also identifying the best practices. In my opinion, it is no longer acceptable to release paradigm changing specifications without also releasing an implementation or best practice guide to go with it.
In regard to the spec itself, I think it is fine. I don't agree with Ole' man Baker that we are just re-inventing HTTP. Pure REST has its place and SOAP has its place. Standardizing verbs is good. I was a bit curious why the group didn't create a 'verb extension' or 'verb introduction' mechanism, but rather just 'hardcoded' a handful of verbs.
IMHO, the creation of four verbs is a good thing. It will make people think about why WS-Transfer is limited, which will lead discussions on why an 'Enterprise Vocabulary' is needed.
1. The game lasts for an hour.
2. When speaking to each other, all engineers are only allowed to use the following verbs: GET, PUT, DELETE and CREATE.
3. All predicates must be spoken in Latin or a language other than your native tongue.
4. Nouns and adjectives may be used but only if they have been written on a common whiteboard first.
Ok, I’m only joking – but you do realize that this is the game the web service engineers are being told to play with business systems.
What do I think of WS-Transfer? Easy, we have now created a vocabulary of four common words. At this pace, we should catch up to the pre-historic cave man in about 20-25 more years.
Don Box makes an interesting comment. He basically states that using four verbs can be dangerous. And I agree. However, I am of the opinion that the WS-* spec teams are doing a severe disservice to the community by releasing these specifications without also identifying the best practices. In my opinion, it is no longer acceptable to release paradigm changing specifications without also releasing an implementation or best practice guide to go with it.
In regard to the spec itself, I think it is fine. I don't agree with Ole' man Baker that we are just re-inventing HTTP. Pure REST has its place and SOAP has its place. Standardizing verbs is good. I was a bit curious why the group didn't create a 'verb extension' or 'verb introduction' mechanism, but rather just 'hardcoded' a handful of verbs.
IMHO, the creation of four verbs is a good thing. It will make people think about why WS-Transfer is limited, which will lead discussions on why an 'Enterprise Vocabulary' is needed.
Saturday, September 11, 2004
Value-Added-Clown (VAC)
A recent IM conversation (names changed to protect the innocent)
----------------
BILL says:
I have a couple of developers working for me and I'm not terribly impressed with their abilities thus far.
BILL says:
I'm working for XYZ Finance Company
Jeff Schneider says:
*use opportunity to learn more about Finance software*
BILL says:
they were wanting to use SWT as their UI technology
Jeff Schneider says:
screw SWT and UI
BILL says:
is there something to gain from learning about finance software?
Jeff Schneider says:
learn finance domain
BILL says:
SWT blows
BILL says:
what is the advantage that I should be looking at with Finance domain?
Jeff Schneider says:
Business domain is more important than changing technology
BILL says:
yeah, I'm figuring that out
BILL says:
from a manager's POV, how should I approach my manager to tell him I don't think my developers are cutting it (if I perceive that)
Jeff Schneider says:
value is a function of cost over output
Jeff Schneider says:
make sure you know what the cost are before determining value
Jeff Schneider says:
(you see output)
BILL says:
you mean cost of bringing in new developers and getting them up to speed?
Jeff Schneider says:
if he's paying $4/hour for current people than you may be giving him bad advice
BILL says:
true
Jeff Schneider says:
don't advise until you know costs
BILL says:
aha
BILL says:
since I don't know their rates, I can't make that call then
BILL says:
right?
Jeff Schneider says:
yep - but feel free to ask
BILL says:
is that something they call tell me?
Jeff Schneider says:
sure
Jeff Schneider says:
you should also ask the manager if he/she wants your input on such items
BILL says:
what other info should factor into that decision?
Jeff Schneider says:
(output, quality, etc)
BILL says:
it has been relayed to me that I should advise on such matters so I assume that is a responsibility for me
BILL says:
but I should assume nothing
Jeff Schneider says:
if mgr doesn't want to tell then tell him what the perceived bill rate of person is "I'm guessing that your paying about $35/hr for Balu - - which seems appropriate..."
BILL says:
ok
BILL says:
you tell me if this would be a warning sign to you
BILL says:
I asked one to write a Java2D demo (as a replacement for a flash module) that was a simple graph that when values were changed, the graph adjusted)
BILL says:
he proceeded to download sample code from Sun and paste it and tried to modify it (this was after he told me he felt very comfy with Java2D)
BILL says:
would that be a red flag?
Jeff Schneider says:
maybe - but not necessarily...
BILL says:
what would your thoughts be?
Jeff Schneider says:
1. I'd assume person lied about expertise in the technology (people always do)
BILL says:
oh yeah, I had to help him get a demo going cuz he couldn't figure out his compiler error (tried to instantiate an anon inner class from a main)
Jeff Schneider says:
2. I'd be more concerned about ability to get up to speed and then get dedicated to knocking it out
BILL says:
yeah, I've already figured out that they lied
Jeff Schneider says:
3. Then concerned about willingness to refactor until the design was correct (on his own dollar)
BILL says:
would you say micromanagement is going to be my best bet at getting this delivered as it should be?
Jeff Schneider says:
no, but tight iterations would be advised
BILL says:
yeah, weekly code reviews a good thing?
BILL says:
I'm already drawing up a standards doc as a guide
Jeff Schneider says:
sure, lots of builds, demos with mgmt, etc
Jeff Schneider says:
Visibility = "Putting glass box around large turd."
BILL says:
hehe
BILL says:
kewl
Jeff Schneider says:
your first duty is to make them succeed though
BILL says:
right
Jeff Schneider says:
more times than not, you'll end up with Bozo's on your team. Great engineers are ones that can turn clowns into productive team members
BILL says:
guess that would be a good test of my ability ?
BILL says:
hehe
BILL says:
how yucky
Jeff Schneider says:
yep - but that's what separates the pack
Jeff Schneider says:
give mgmt visibility while backing clowns
-----------------
So, I really believe the advice that I gave to *Bill*. Any jack ass can throw another incompetent engineer under the car. The manager should have visibility into *suspect* engineers, but until a *suspect* is proven guilty, it is the job of the more senior engineer to make the rest of the team succeed.
----------------
BILL says:
I have a couple of developers working for me and I'm not terribly impressed with their abilities thus far.
BILL says:
I'm working for XYZ Finance Company
Jeff Schneider says:
*use opportunity to learn more about Finance software*
BILL says:
they were wanting to use SWT as their UI technology
Jeff Schneider says:
screw SWT and UI
BILL says:
is there something to gain from learning about finance software?
Jeff Schneider says:
learn finance domain
BILL says:
SWT blows
BILL says:
what is the advantage that I should be looking at with Finance domain?
Jeff Schneider says:
Business domain is more important than changing technology
BILL says:
yeah, I'm figuring that out
BILL says:
from a manager's POV, how should I approach my manager to tell him I don't think my developers are cutting it (if I perceive that)
Jeff Schneider says:
value is a function of cost over output
Jeff Schneider says:
make sure you know what the cost are before determining value
Jeff Schneider says:
(you see output)
BILL says:
you mean cost of bringing in new developers and getting them up to speed?
Jeff Schneider says:
if he's paying $4/hour for current people than you may be giving him bad advice
BILL says:
true
Jeff Schneider says:
don't advise until you know costs
BILL says:
aha
BILL says:
since I don't know their rates, I can't make that call then
BILL says:
right?
Jeff Schneider says:
yep - but feel free to ask
BILL says:
is that something they call tell me?
Jeff Schneider says:
sure
Jeff Schneider says:
you should also ask the manager if he/she wants your input on such items
BILL says:
what other info should factor into that decision?
Jeff Schneider says:
(output, quality, etc)
BILL says:
it has been relayed to me that I should advise on such matters so I assume that is a responsibility for me
BILL says:
but I should assume nothing
Jeff Schneider says:
if mgr doesn't want to tell then tell him what the perceived bill rate of person is "I'm guessing that your paying about $35/hr for Balu - - which seems appropriate..."
BILL says:
ok
BILL says:
you tell me if this would be a warning sign to you
BILL says:
I asked one to write a Java2D demo (as a replacement for a flash module) that was a simple graph that when values were changed, the graph adjusted)
BILL says:
he proceeded to download sample code from Sun and paste it and tried to modify it (this was after he told me he felt very comfy with Java2D)
BILL says:
would that be a red flag?
Jeff Schneider says:
maybe - but not necessarily...
BILL says:
what would your thoughts be?
Jeff Schneider says:
1. I'd assume person lied about expertise in the technology (people always do)
BILL says:
oh yeah, I had to help him get a demo going cuz he couldn't figure out his compiler error (tried to instantiate an anon inner class from a main)
Jeff Schneider says:
2. I'd be more concerned about ability to get up to speed and then get dedicated to knocking it out
BILL says:
yeah, I've already figured out that they lied
Jeff Schneider says:
3. Then concerned about willingness to refactor until the design was correct (on his own dollar)
BILL says:
would you say micromanagement is going to be my best bet at getting this delivered as it should be?
Jeff Schneider says:
no, but tight iterations would be advised
BILL says:
yeah, weekly code reviews a good thing?
BILL says:
I'm already drawing up a standards doc as a guide
Jeff Schneider says:
sure, lots of builds, demos with mgmt, etc
Jeff Schneider says:
Visibility = "Putting glass box around large turd."
BILL says:
hehe
BILL says:
kewl
Jeff Schneider says:
your first duty is to make them succeed though
BILL says:
right
Jeff Schneider says:
more times than not, you'll end up with Bozo's on your team. Great engineers are ones that can turn clowns into productive team members
BILL says:
guess that would be a good test of my ability ?
BILL says:
hehe
BILL says:
how yucky
Jeff Schneider says:
yep - but that's what separates the pack
Jeff Schneider says:
give mgmt visibility while backing clowns
-----------------
So, I really believe the advice that I gave to *Bill*. Any jack ass can throw another incompetent engineer under the car. The manager should have visibility into *suspect* engineers, but until a *suspect* is proven guilty, it is the job of the more senior engineer to make the rest of the team succeed.
Sunday, September 05, 2004
The Mob Effect on the CEO
I've been witness to a recent phenomenon. I don't know what to call it, but I'll attempt to describe it to you.
Software companies have been hiring huge teams (Mobs) of programmers in India and other low cost labor supply areas. The purpose for these hires is to 'create more software, faster'.
When the CEO goes to see the Mob they get excited. They see dozens of cheap bodies lined up and ready to work on whatever brilliant idea is floating in the heads of the executive team. They become drunk on this new, cheap power. They get 'beer muscles'. At the sight of all of these cheap bodies they feel like they have their own little army and can take on the world (or at least a larger competitor). And this is where it begins.
Mob Mania has struck more CEO's than I can count. With their new perceived power they begin to do the unthinkable. They build products in spaces where they know very little. They create a 'portfolio of checkmarks'; that is, they build products purely for the sake of rounding out a portfolio and checking off products. Checkmark Portfolios are never about having the best product - they are about having all products. It is almost an acknowledgment that the executive team was too stupid or lazy to do their homework and determine which products really needed to be built and which should have been OEM'd or left out of the portfolio all together.
Checkmark Portfolios lead to an interesting destination. Buyers see dozens of vendors all claiming to have the exact same set of products. They look under the covers and find that the products were designed with minimal depth while maximizing breadth. The amazing similarity of the products being offered by direct competitors leads to a new buying process.
Now, the focus is moving off of: 1. Having the product or 2. Having the rounded portfolio and since the product was built at dirt cheap prices, the focus usually isn't on the price. The focus is on 'trust'. Said another way, the focus is on brand.
Like all products that are easily commoditizable, the focus moves off of product differentiation and to brand awareness and brand identity. However, it is an interesting time to create brands. With the low investment model required to create a Mob, more and more small companies are sprouting up determined to get a piece of the action (many of these companies are now based in Europe or South East Asia).
The room of vendors is crowded and everyone is yelling for attention. The CEO sees this and thinks two things:
1. "It's going to cost some serious money to get my message above the noise level."
2. "Oh shit, what an awful time to have a commoditized product."
Life has taught me that heard mentality pays for the few. I've seen it over and over again. I watched the VC's pull a heard model and now I watch another. The leaders of the heard will win. The followers will be left in the dust. Second and third tier ISV's will be crushed in a battle whose outcome is so obvious that it is almost uninteresting.
Software companies have been hiring huge teams (Mobs) of programmers in India and other low cost labor supply areas. The purpose for these hires is to 'create more software, faster'.
When the CEO goes to see the Mob they get excited. They see dozens of cheap bodies lined up and ready to work on whatever brilliant idea is floating in the heads of the executive team. They become drunk on this new, cheap power. They get 'beer muscles'. At the sight of all of these cheap bodies they feel like they have their own little army and can take on the world (or at least a larger competitor). And this is where it begins.
Mob Mania has struck more CEO's than I can count. With their new perceived power they begin to do the unthinkable. They build products in spaces where they know very little. They create a 'portfolio of checkmarks'; that is, they build products purely for the sake of rounding out a portfolio and checking off products. Checkmark Portfolios are never about having the best product - they are about having all products. It is almost an acknowledgment that the executive team was too stupid or lazy to do their homework and determine which products really needed to be built and which should have been OEM'd or left out of the portfolio all together.
Checkmark Portfolios lead to an interesting destination. Buyers see dozens of vendors all claiming to have the exact same set of products. They look under the covers and find that the products were designed with minimal depth while maximizing breadth. The amazing similarity of the products being offered by direct competitors leads to a new buying process.
Now, the focus is moving off of: 1. Having the product or 2. Having the rounded portfolio and since the product was built at dirt cheap prices, the focus usually isn't on the price. The focus is on 'trust'. Said another way, the focus is on brand.
Like all products that are easily commoditizable, the focus moves off of product differentiation and to brand awareness and brand identity. However, it is an interesting time to create brands. With the low investment model required to create a Mob, more and more small companies are sprouting up determined to get a piece of the action (many of these companies are now based in Europe or South East Asia).
The room of vendors is crowded and everyone is yelling for attention. The CEO sees this and thinks two things:
1. "It's going to cost some serious money to get my message above the noise level."
2. "Oh shit, what an awful time to have a commoditized product."
Life has taught me that heard mentality pays for the few. I've seen it over and over again. I watched the VC's pull a heard model and now I watch another. The leaders of the heard will win. The followers will be left in the dust. Second and third tier ISV's will be crushed in a battle whose outcome is so obvious that it is almost uninteresting.
Saturday, September 04, 2004
Things are busy...
Well, I've been busy.
We've seen our consulting business pick up considerably and the sales pipeline remains very strong. Momentum has been adding a new employee about every 5 days and I believe this will continue through the end of the year.
Most of our projects now have some component of web services. Here is a sampling:
- SOAP gateways to access legacy systems
- business objects being converted to business services; data layers being turned into data services
- laying down foundational ws-infrastructure (policy, monitoring, balancing, etc.)
Some other trends:
- desire to have pure SOAP as well as a slimmed down XML services (no RM, Sec or TR)
- "ESB" has made its way into RFP's
- brand awareness of ws-pure plays is much higher (Systinet, Blue Titan, AmberPoint, etc.)
Still, the world remains divided on how they view web services. As I recently told one of our customers:
"The web service protocols are at an adoption level equivalent to where you may have found TCP/IP in 1993 or 1994. Mass adoption has not yet occurred, but the writing is on the wall and no one is buying proprietary standards (Novell IPX/SPX). As we begin 2005, web services will enter into their 5th year in existence and remain the cornerstone strategy for vendors like IBM, SAP and Microsoft. This must be part of any go forward integration strategy for a Fortune 2000 company."
Come to think of it... some of those customers are still running IPX/SPX :-)
We've seen our consulting business pick up considerably and the sales pipeline remains very strong. Momentum has been adding a new employee about every 5 days and I believe this will continue through the end of the year.
Most of our projects now have some component of web services. Here is a sampling:
- SOAP gateways to access legacy systems
- business objects being converted to business services; data layers being turned into data services
- laying down foundational ws-infrastructure (policy, monitoring, balancing, etc.)
Some other trends:
- desire to have pure SOAP as well as a slimmed down XML services (no RM, Sec or TR)
- "ESB" has made its way into RFP's
- brand awareness of ws-pure plays is much higher (Systinet, Blue Titan, AmberPoint, etc.)
Still, the world remains divided on how they view web services. As I recently told one of our customers:
"The web service protocols are at an adoption level equivalent to where you may have found TCP/IP in 1993 or 1994. Mass adoption has not yet occurred, but the writing is on the wall and no one is buying proprietary standards (Novell IPX/SPX). As we begin 2005, web services will enter into their 5th year in existence and remain the cornerstone strategy for vendors like IBM, SAP and Microsoft. This must be part of any go forward integration strategy for a Fortune 2000 company."
Come to think of it... some of those customers are still running IPX/SPX :-)
Wednesday, August 11, 2004
Seminar: Architecting the Enterprise Service Network
I've been giving closed-audience presentations on the SOE and service networks for over three years now. I finally feel like the material is good enough to do the road show.
So, if I hit the road with my PowerPoints and bright smile... where do you want me to go (cities)? U.S. or otherwise.
Send me a note. The more interest, the more likely I'll add it to the list. jschneider@momentumsoftware.com
So, if I hit the road with my PowerPoints and bright smile... where do you want me to go (cities)? U.S. or otherwise.
Send me a note. The more interest, the more likely I'll add it to the list. jschneider@momentumsoftware.com
Thursday, August 05, 2004
Table Oriented Programming
I have found the following site fascinating as a complementary programming style to service oriented: http://www.geocities.com/tablizer/top.htm (thanks Hugh)
Object oriented programming tends to put nouns as the primary concern, while services have been leaning towards verbs. The discussion on Table Oriented Programming has me thinking that there isn't a need to make either the noun or the verb the primary concern. Rather, the focus should be to enable both in an equivalent manner.
Object oriented programming tends to put nouns as the primary concern, while services have been leaning towards verbs. The discussion on Table Oriented Programming has me thinking that there isn't a need to make either the noun or the verb the primary concern. Rather, the focus should be to enable both in an equivalent manner.
Wednesday, July 28, 2004
Disposable Applications
In the early 90's, the company that I worked for had 3 different application platform strategies:
1. Purchase large, off-the-shelf (OTS) packaged apps
2. Build applications that were core to the business (Core)
3. Build rapid apps for non-core or non-long-living applications (Non-Core)
Back in those days, we used PowerBuilder for #2 (Core). PowerBuilder gave us enough structured techniques to build fairly complex business applications. It recognized the number one use case in business apps: Capture user information, Save it, Make it available to others. Surprisingly, this DB intensive technique could be used on a high percentage of problems. It stunk at workflow / groupware - but luckily this is when Lotus Notes was emerging. Now we had a tool that could rapidly create collaboration environments for non-structured data. We could also use the people in the company who couldn't code worth a shit (and we couldn't fire) to actually get something done. Yes, we called this people "Notes Programmers". And we had a ton of them.
Generally speaking, we considered the Notes team to be creating 'Disposable Applications'. The people were cheap, the licensing was cheap enough, and the throughput was high. We allowed them to knock out small applications - and they did - they churned through them. Then an interesting thing happened... our users started telling us that they wanted the new application to be done in Notes (not PowerBuilder). "What? You want it in Notes??? Those are the idiot programmers that we couldn't fire." I thought to myself.
An interesting dynamic had occurred. Our users realized a handful of things:
1. The Notes team delivered applications faster than the PowerBuilder team.
2. The Notes team didn't make the users feel like technical idiots; thus they became friends with the team.
3. On occasion, the users would make small changes to the Notes applications themselves.
4. The users realized that in addition to collecting, storing and retrieving data, virtually all business processes involve workflow and collaboration. In fact, the collaboration was often more important than the structured data.
I have the unique opportunity of seeing lots of service oriented offerings. Virtually all of them are of the 'PowerBuilder' classification. Most of them start off by integrating into Eclipse or Visual Studio. Ok - with this as a starting point you have already determined that you aren't a disposable application. The next thing that I see is that vendors expect people to understand XML Schema. This again, precludes the disposable community. Should they know XSLT? Nope. BPEL? Hell no. XQuery? Uh... No.
In order to create a Disposable Application environment around a service oriented infrastructure, one thing is absolutely necessary:
- The developer / author shouldn't have to know anything about SOA. No Exceptions.
Most talented engineers hate environments like Lotus Notes. They roll their eyes thinking about scripting hell, inability to enforce uniform constraints and business logic, inability to leverage a common data model and perhaps most significant, it allows dumb shits to look smart.
Talented engineers would much rather create a distributed state machine leveraging a set of 30 WS-Protocols across a messaging infrastructure that leverages a VM that facilitates heap size manipulation, while programming to a set of 17,000 classes that represent the "enterprise API". And oddly, customers are preferring to buy packaged applications that are already fully developed over having custom apps built. Who'd have guessed that one?
So, you ask, am I in favor of disposable applications? Hell yes. It may hurt your ego but it will be kind to your wallet. The real trick is to determine how to design a service network to facilitate disposable applications. It should be possible to create a constrained and structured set of services that contain the end development environment enough to allow 'power users' to do their thing. Then, it is off to the races.
1. Purchase large, off-the-shelf (OTS) packaged apps
2. Build applications that were core to the business (Core)
3. Build rapid apps for non-core or non-long-living applications (Non-Core)
Back in those days, we used PowerBuilder for #2 (Core). PowerBuilder gave us enough structured techniques to build fairly complex business applications. It recognized the number one use case in business apps: Capture user information, Save it, Make it available to others. Surprisingly, this DB intensive technique could be used on a high percentage of problems. It stunk at workflow / groupware - but luckily this is when Lotus Notes was emerging. Now we had a tool that could rapidly create collaboration environments for non-structured data. We could also use the people in the company who couldn't code worth a shit (and we couldn't fire) to actually get something done. Yes, we called this people "Notes Programmers". And we had a ton of them.
Generally speaking, we considered the Notes team to be creating 'Disposable Applications'. The people were cheap, the licensing was cheap enough, and the throughput was high. We allowed them to knock out small applications - and they did - they churned through them. Then an interesting thing happened... our users started telling us that they wanted the new application to be done in Notes (not PowerBuilder). "What? You want it in Notes??? Those are the idiot programmers that we couldn't fire." I thought to myself.
An interesting dynamic had occurred. Our users realized a handful of things:
1. The Notes team delivered applications faster than the PowerBuilder team.
2. The Notes team didn't make the users feel like technical idiots; thus they became friends with the team.
3. On occasion, the users would make small changes to the Notes applications themselves.
4. The users realized that in addition to collecting, storing and retrieving data, virtually all business processes involve workflow and collaboration. In fact, the collaboration was often more important than the structured data.
I have the unique opportunity of seeing lots of service oriented offerings. Virtually all of them are of the 'PowerBuilder' classification. Most of them start off by integrating into Eclipse or Visual Studio. Ok - with this as a starting point you have already determined that you aren't a disposable application. The next thing that I see is that vendors expect people to understand XML Schema. This again, precludes the disposable community. Should they know XSLT? Nope. BPEL? Hell no. XQuery? Uh... No.
In order to create a Disposable Application environment around a service oriented infrastructure, one thing is absolutely necessary:
- The developer / author shouldn't have to know anything about SOA. No Exceptions.
Most talented engineers hate environments like Lotus Notes. They roll their eyes thinking about scripting hell, inability to enforce uniform constraints and business logic, inability to leverage a common data model and perhaps most significant, it allows dumb shits to look smart.
Talented engineers would much rather create a distributed state machine leveraging a set of 30 WS-Protocols across a messaging infrastructure that leverages a VM that facilitates heap size manipulation, while programming to a set of 17,000 classes that represent the "enterprise API". And oddly, customers are preferring to buy packaged applications that are already fully developed over having custom apps built. Who'd have guessed that one?
So, you ask, am I in favor of disposable applications? Hell yes. It may hurt your ego but it will be kind to your wallet. The real trick is to determine how to design a service network to facilitate disposable applications. It should be possible to create a constrained and structured set of services that contain the end development environment enough to allow 'power users' to do their thing. Then, it is off to the races.
Monday, July 26, 2004
A Note on BEA
The recent departure of Adam Bosworth from BEA has many in the industry talking about the overarching issues that seem to be facing that company. As an ex-BEA partner, I witnessed first hand several unfortunate but not so uncommon events take place, including:
- trouble with channel conflicts
- strong sales people being fired (even in very tough environments)
- less than capable people hired into marketing and bizdev
- inability to articulate a new vision
- failure to create an open source strategy
- failure to answer the IBM global services threat
- inability to create vertical offerings
- chose not to acquire when their stock price was down - despite industry consolidation
Now, I get the feeling that there were more issues on the inside - but I can only tell you what I witnessed from the outside looking in.
In my opinion, BEA was failing during an absolutely critical period of change in the software industry.
- Venture funds over invested and killed the cash cows of medium sized ISV's
- This fortified the positions of the large ISV's (MS, IBM, SAP)
- Customers were moving to process based applications, not technologies
- Large ISV's moved to an agility based packaged app model
This set the stage for:
-- Microsoft building out .Net and growing Microsoft Business Solutions
-- IBM will build out WebSphere and acquire packaged app companies (Siebel, etc.)
-- SAP continuing the component/service push on NetWeaver
-- Oracle continues to build apps and grow the technology platform (Collaxa acquisition, etc.)
All in all, we are seeing a trend; major application companies are going to market with an application platform that they provide. Smaller ISV's are often picking JBoss or .Net. And medium sized businesses are being attacked by aggressive IBM sales teams.
So, where does this leave BEA?
For starters, BEA should have seen this coming and pushed a deal with either SAP or Oracle some time back. Upon seeing that Open Source offerings was having a significant effect on the low end of the ISV market via rapid commoditization, BEA needed to make a move. Going forward, variations of open source models will dominate markets that are easy to commoditize. Integration will likely be on of those markets - technologist understand the use cases.
The departure of Adam Bosworth is only one of many issues for this company. Although their products are sound (from a Java perspective), they moved extremely slowly in their web services strategy. Could BEA acquire enough companies to be considered a 'service oriented infrastructure' company? Maybe - but the market is up and the web service startups are making sales which will substantially increase their valuations. This makes it much tougher to stomach the acquisitions. Let's say they pull it off. Is it a good move? I'm not sure. Mostly, I think it just keeps them around until the next wave of mergers takes place.
I wish that I could offer BEA some magical advice. It is a company that has been good for the software community. I don't have the answer, but I have some inclinations:
1. From a technical perspective, look beyond Java. And way beyond J2EE.
2. QuickSilver and the ESB space are already commoditized. Back an open source project.
3. Web Services are easy, "Integrated Service Networks" are hard.
4. Understand why people like the idea of a "Google computing platform"
5. Packaged apps will dominate until the build vs. buy dynamics reverse. Unless you plan on being acquired soon, your job is to reverse it. It's that simple.
As I look at these 5 items, I realize that this is good advice for any of the ISV's that plays in the app-dev, or integration space. Here are a couple more things to chew on:
- web services and service networks increase the complexity of the enterprise I.T. stack
- the more moving parts there are the more it costs to bring them together
- not all buyers need the same level of complexity (if only we had J2EE Beginners version, J2EE advanced version, etc.)
- service oriented infrastructure will be most beneficial to very large I.T. shops
- if you refactor software out of the application and into the network, you should be able to reduce the development and integration time - if you didn't; you failed.
- Remember - dBase, PowerBuilder and ColdFusion. Developers like when you make them look like rock stars - give them the tools to beat expectations.
I feel a bit sorry for them, but mostly I'm mad. As the turnover continues at BEA we can be hopeful that they'll either acquire the companies with the talent or bring in some new vision to steer the ship. Despite my frustrations with them, I wish them the best of luck.
- trouble with channel conflicts
- strong sales people being fired (even in very tough environments)
- less than capable people hired into marketing and bizdev
- inability to articulate a new vision
- failure to create an open source strategy
- failure to answer the IBM global services threat
- inability to create vertical offerings
- chose not to acquire when their stock price was down - despite industry consolidation
Now, I get the feeling that there were more issues on the inside - but I can only tell you what I witnessed from the outside looking in.
In my opinion, BEA was failing during an absolutely critical period of change in the software industry.
- Venture funds over invested and killed the cash cows of medium sized ISV's
- This fortified the positions of the large ISV's (MS, IBM, SAP)
- Customers were moving to process based applications, not technologies
- Large ISV's moved to an agility based packaged app model
This set the stage for:
-- Microsoft building out .Net and growing Microsoft Business Solutions
-- IBM will build out WebSphere and acquire packaged app companies (Siebel, etc.)
-- SAP continuing the component/service push on NetWeaver
-- Oracle continues to build apps and grow the technology platform (Collaxa acquisition, etc.)
All in all, we are seeing a trend; major application companies are going to market with an application platform that they provide. Smaller ISV's are often picking JBoss or .Net. And medium sized businesses are being attacked by aggressive IBM sales teams.
So, where does this leave BEA?
For starters, BEA should have seen this coming and pushed a deal with either SAP or Oracle some time back. Upon seeing that Open Source offerings was having a significant effect on the low end of the ISV market via rapid commoditization, BEA needed to make a move. Going forward, variations of open source models will dominate markets that are easy to commoditize. Integration will likely be on of those markets - technologist understand the use cases.
The departure of Adam Bosworth is only one of many issues for this company. Although their products are sound (from a Java perspective), they moved extremely slowly in their web services strategy. Could BEA acquire enough companies to be considered a 'service oriented infrastructure' company? Maybe - but the market is up and the web service startups are making sales which will substantially increase their valuations. This makes it much tougher to stomach the acquisitions. Let's say they pull it off. Is it a good move? I'm not sure. Mostly, I think it just keeps them around until the next wave of mergers takes place.
I wish that I could offer BEA some magical advice. It is a company that has been good for the software community. I don't have the answer, but I have some inclinations:
1. From a technical perspective, look beyond Java. And way beyond J2EE.
2. QuickSilver and the ESB space are already commoditized. Back an open source project.
3. Web Services are easy, "Integrated Service Networks" are hard.
4. Understand why people like the idea of a "Google computing platform"
5. Packaged apps will dominate until the build vs. buy dynamics reverse. Unless you plan on being acquired soon, your job is to reverse it. It's that simple.
As I look at these 5 items, I realize that this is good advice for any of the ISV's that plays in the app-dev, or integration space. Here are a couple more things to chew on:
- web services and service networks increase the complexity of the enterprise I.T. stack
- the more moving parts there are the more it costs to bring them together
- not all buyers need the same level of complexity (if only we had J2EE Beginners version, J2EE advanced version, etc.)
- service oriented infrastructure will be most beneficial to very large I.T. shops
- if you refactor software out of the application and into the network, you should be able to reduce the development and integration time - if you didn't; you failed.
- Remember - dBase, PowerBuilder and ColdFusion. Developers like when you make them look like rock stars - give them the tools to beat expectations.
I feel a bit sorry for them, but mostly I'm mad. As the turnover continues at BEA we can be hopeful that they'll either acquire the companies with the talent or bring in some new vision to steer the ship. Despite my frustrations with them, I wish them the best of luck.
Saturday, July 24, 2004
Distributed Noun Processing
Lately, I've been very concerned about the state of Service Network designs.
The service oriented world puts an emphasis on verbs (authenticate, format, translate, etc.) This forces the knowledge about nouns to be distributed across a set of services. Service oriented programming usually looks like a pipelined or staged computing model. Often the messages that are being processed refer to the same schema. However, the processing instructions vary according to the specifics of the schema.
Let's say that we have a four stage service plan:
Step 1 - pull message off of bus and authenticate
Step 2 - transform message according to local needs
Step 3 - process business service
Step 4 - business services encapsulates a call to a data service
Each service focuses on one stage and will typically have a control language (DSL) for performing functions on the nouns (business schemas) that are passed to it. What seems to be missing from most commercial and homegrown services is the ability for a service to easily add or modify the nouns that it is aware of or modify the routines that perform the functions on those nouns.
This is a huge issue. For some reason, people continue to focus on the virtues of SOA/WS-*; loose coupling, reusability, etc. However, they are not talking about the new problem: Distributed Noun Processing. The realization of a use case is now spread across multiple services. Changes to nouns will likely result in changes to all services in the plan. It is likely that the DB schema changes, the O/R plan changes, the XSLT changes, the message type in the WSDL changes, the evaluation logic in the business class changes. The impact of noun changes must be measured (part of the agility/fragility index).
Now a seasoned person might say, "but that is the current state of art as well". Yes - this is true. Generally speaking J2ee and .Net fail to provide facilities for cross-cutting functional concerns across their tiers. So, the good news is that we're only failing as bad as we did last time. However, I think we failed pretty hard last time.
As we look at services, we must identify the best programming model associated with the functionality. Generally speaking, this means that services rely on specialized verb engines. These verb engines usually rely on their own DSL (think DML and DDL for relational databases, axiom languages for business rules, transformation languages, etc.) As the number of DSL's increases, so does the importance of coordinating changes across them.
At Momentum, we have been spending a significant amount of time looking at this issue. We have not found the magic "DSL propagation language" yet, nor do we expect to anytime soon. The MDA world has made progress but is still very disconnected from the service oriented world. For now, the effort is either done by hand or with some tooling that helps to automate impact and change management across a set of predetermined DSL's. Failure to manage the service network from a functional perspective will likely lead to excessive costs for new application introduction and change management. Trust me - get it under control now.
The service oriented world puts an emphasis on verbs (authenticate, format, translate, etc.) This forces the knowledge about nouns to be distributed across a set of services. Service oriented programming usually looks like a pipelined or staged computing model. Often the messages that are being processed refer to the same schema. However, the processing instructions vary according to the specifics of the schema.
Let's say that we have a four stage service plan:
Step 1 - pull message off of bus and authenticate
Step 2 - transform message according to local needs
Step 3 - process business service
Step 4 - business services encapsulates a call to a data service
Each service focuses on one stage and will typically have a control language (DSL) for performing functions on the nouns (business schemas) that are passed to it. What seems to be missing from most commercial and homegrown services is the ability for a service to easily add or modify the nouns that it is aware of or modify the routines that perform the functions on those nouns.
This is a huge issue. For some reason, people continue to focus on the virtues of SOA/WS-*; loose coupling, reusability, etc. However, they are not talking about the new problem: Distributed Noun Processing. The realization of a use case is now spread across multiple services. Changes to nouns will likely result in changes to all services in the plan. It is likely that the DB schema changes, the O/R plan changes, the XSLT changes, the message type in the WSDL changes, the evaluation logic in the business class changes. The impact of noun changes must be measured (part of the agility/fragility index).
Now a seasoned person might say, "but that is the current state of art as well". Yes - this is true. Generally speaking J2ee and .Net fail to provide facilities for cross-cutting functional concerns across their tiers. So, the good news is that we're only failing as bad as we did last time. However, I think we failed pretty hard last time.
As we look at services, we must identify the best programming model associated with the functionality. Generally speaking, this means that services rely on specialized verb engines. These verb engines usually rely on their own DSL (think DML and DDL for relational databases, axiom languages for business rules, transformation languages, etc.) As the number of DSL's increases, so does the importance of coordinating changes across them.
At Momentum, we have been spending a significant amount of time looking at this issue. We have not found the magic "DSL propagation language" yet, nor do we expect to anytime soon. The MDA world has made progress but is still very disconnected from the service oriented world. For now, the effort is either done by hand or with some tooling that helps to automate impact and change management across a set of predetermined DSL's. Failure to manage the service network from a functional perspective will likely lead to excessive costs for new application introduction and change management. Trust me - get it under control now.
Friday, July 16, 2004
Composite Application: Def #1
Phil at Loosely Coupled was kind enough to send me a definition of "composite application":
================================
Here’s Loosely Coupled’s definition:
An application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems).
http://looselycoupled.com/glossary/composite%20application
It’s a favourite term of Gartner’s Massimo Pessini, the man who also gave us ‘ESB’
================================
I had great conversations on this topic recently with some really smart people. Unfortunately we were all rather drunk and I don't remember what we concluded - although I think it had something to do with molecules. Ok, this in only partially true. We basically agreed that the definitions of composite apps was still too loose (SOI, SODA, integration at the glass, how many of the NFR's need to be addressed by services, how much of the app needs to be SO enabled, etc.) Bottom line is that we need to move to a 'definition by constraints' view.
================================
Here’s Loosely Coupled’s definition:
An application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems).
http://looselycoupled.com/glossary/composite%20application
It’s a favourite term of Gartner’s Massimo Pessini, the man who also gave us ‘ESB’
================================
I had great conversations on this topic recently with some really smart people. Unfortunately we were all rather drunk and I don't remember what we concluded - although I think it had something to do with molecules. Ok, this in only partially true. We basically agreed that the definitions of composite apps was still too loose (SOI, SODA, integration at the glass, how many of the NFR's need to be addressed by services, how much of the app needs to be SO enabled, etc.) Bottom line is that we need to move to a 'definition by constraints' view.
ToDo: Create Agility Index
On my list of things to do is to create an agility index (and a fragility index). Before I go too far down the road I thought I'd post to see if anyone already has a favorite agility/fragility index in use. Lemme know.
Oh yea... so it isn't about being service oriented. Service networks must be evaluated from an 'ility' perspective. I'll start with agility.
Oh yea... so it isn't about being service oriented. Service networks must be evaluated from an 'ility' perspective. I'll start with agility.
Monday, July 12, 2004
Nice paper
Google led me to this nice paper by ACM Fellow, Carlo Ghezzi:
http://www.elet.polimi.it/upload/ghezzi/_PRIVATE/paper.pdf
http://www.elet.polimi.it/upload/ghezzi/_PRIVATE/paper.pdf
Subscribe to:
Posts (Atom)