Here are my top 100 predictions for the SOA community:
#1 - The incredible value of SaaS is realized and buyers want in
#2 - The buyers realize they need enterprise SOA to effectively pull off SaaS
#3 - #100 are irrelevant.
Sunday, December 30, 2007
Wednesday, December 19, 2007
Updating the SOA Scorecard: SCA Services
For almost 5 years now, we've been advising clients on their SOA scorecard. In the early days of SOA adoption, customers often measure their success by 'releasing services'. This is a great metric for beginners. As the program progresses the shift moves to their utilization. Services are only valuable if they are actually used. From this perspective, we recommend looking at the consumer-to-service ratio as the primary test. The secondary test looks at message counts; that is, are the services actually being called.
Unfortunately, neither of these tests actually look at the value that software brings to the business. We've been encouraging our customers to spend more time looking at the business proposition that the service reflects. Business strategy is based on those activities and assets which are considered 'Sustainable Competitive Advantages' or SCA. These are the things that allows a company to be successful in their business year after year. Strategist have various means of identifying and describing the SCA's. Moore's 'core vs. context', and 'value chains' are often applied to help an organization understand where they need to be competitive.
Many organizations have moved beyond SOA pilots and now have scores of services running in production. However, many of these same organizations do not have the truly important services available. The fixation to increase the number of services often overrides the commonsense notion of providing business-valued services.
I've been encouraging customers to look at the three C's of business: Customers, Commerce and Channel. All three of these domains are typically excellent candidate for service enablement with high business value. Obviously, there are other domains that might be more important for your business which should be prioritized higher. The point is that you need to create a priority list of services based on the business that you're in. Service enabling non-valued added aspects of the business might look good on an old fashion SOA scorecard, but it no longer passes the smell test!
Unfortunately, neither of these tests actually look at the value that software brings to the business. We've been encouraging our customers to spend more time looking at the business proposition that the service reflects. Business strategy is based on those activities and assets which are considered 'Sustainable Competitive Advantages' or SCA. These are the things that allows a company to be successful in their business year after year. Strategist have various means of identifying and describing the SCA's. Moore's 'core vs. context', and 'value chains' are often applied to help an organization understand where they need to be competitive.
Many organizations have moved beyond SOA pilots and now have scores of services running in production. However, many of these same organizations do not have the truly important services available. The fixation to increase the number of services often overrides the commonsense notion of providing business-valued services.
I've been encouraging customers to look at the three C's of business: Customers, Commerce and Channel. All three of these domains are typically excellent candidate for service enablement with high business value. Obviously, there are other domains that might be more important for your business which should be prioritized higher. The point is that you need to create a priority list of services based on the business that you're in. Service enabling non-valued added aspects of the business might look good on an old fashion SOA scorecard, but it no longer passes the smell test!
Friday, December 14, 2007
Amazon SimpleDB Launches
Amazon Web Services has launched their latest offering, "Amazon SimpleDB":
SimpleDB sits on top of their hosted computing layer (EC2), proving an integrated cost model for those who are already EC2 customers. From a developer perspective, SimpleDB looks more like a big 'hashtable in the cloud' than a traditional RDBMS. The database is not relational and doesn't support SQL for data definition or data manipulation (DDL/DML). Instead, they have chosen to use a 'schemaless' system for data definition (name/value pairs) and for data manipulation (insert, update, delete) they have chosen to use simple REST style verbs (PUT, GET, DELETE, CREATE, QUERY).
The service is specifically designed for small payloads (not big BLOBS). For larger files, they recommend that you use AWS S3. They also recommend that you only run 'real time queries'. In fact, query execution time is limited to 5 seconds which prevent users from running very large requests. Although some might disagree with this decision, I'm a full supporter of this model. However, organizations will still need to perform two vital operations: 1. Export all data 2. Perform complex BI style queries. It is currently not clear how these items will be supported. The system doesn't seem to support the notion of 'change data capture' which would allow changed records to be sent to a separate analytics engine, nor am I finding a mechanism to easily load or unload a data store which would be a real issue if you time out after 5 seconds...
SimpleDB is in beta which implies that features have been frozen while bugs are ironed out. My primary concern is that they may have accidentally designed "TooSimpleDB". I love the idea of keeping it simple, but they may have overdone it.
"Amazon SimpleDB provides a simple web services interface to create and store multiple data sets, query your data easily, and return the results."
SimpleDB sits on top of their hosted computing layer (EC2), proving an integrated cost model for those who are already EC2 customers. From a developer perspective, SimpleDB looks more like a big 'hashtable in the cloud' than a traditional RDBMS. The database is not relational and doesn't support SQL for data definition or data manipulation (DDL/DML). Instead, they have chosen to use a 'schemaless' system for data definition (name/value pairs) and for data manipulation (insert, update, delete) they have chosen to use simple REST style verbs (PUT, GET, DELETE, CREATE, QUERY).
The service is specifically designed for small payloads (not big BLOBS). For larger files, they recommend that you use AWS S3. They also recommend that you only run 'real time queries'. In fact, query execution time is limited to 5 seconds which prevent users from running very large requests. Although some might disagree with this decision, I'm a full supporter of this model. However, organizations will still need to perform two vital operations: 1. Export all data 2. Perform complex BI style queries. It is currently not clear how these items will be supported. The system doesn't seem to support the notion of 'change data capture' which would allow changed records to be sent to a separate analytics engine, nor am I finding a mechanism to easily load or unload a data store which would be a real issue if you time out after 5 seconds...
SimpleDB is in beta which implies that features have been frozen while bugs are ironed out. My primary concern is that they may have accidentally designed "TooSimpleDB". I love the idea of keeping it simple, but they may have overdone it.
Wednesday, December 12, 2007
Replace SOA Governance with Expertise?
Owen Pettiford takes a swipe at SOA Governance:
Well, I partially agree with Owen. Let's not forget that much of the doctors training was on the best practices (sanitary environment, cross-checks, standard procedures, etc.)
SOA Governance isn't a magic bullet. But if it is implemented correctly it will prevent (some) people from doing (some) stupid stuff (some) of the time. And I'm ok with that.
He goes on to say:
You could replace "Enterprise SOA" with just about anything and you'd be correct. The problem is that large organizations are filled with people who are non-experts who don't have passion and lack shared vision. It's that simple. Good SOA Governance makes the assumption that statistically, the average person in your organization is, well, average!
See:
http://pettiford.blogspot.com/2007/04/governance-is-not-answer.html
The reasons for this conclusion stems from the drug induced high I was on just after the operation when it occurred to me that I had not just survived the biggest operation of my life because someone "governed" it well (sure it was important that the right people were there and that they had the right tools) – I survived because I had EXPERTS working on me who had TRAINED for YEARS.
Well, I partially agree with Owen. Let's not forget that much of the doctors training was on the best practices (sanitary environment, cross-checks, standard procedures, etc.)
SOA Governance isn't a magic bullet. But if it is implemented correctly it will prevent (some) people from doing (some) stupid stuff (some) of the time. And I'm ok with that.
He goes on to say:
Enterprise SOA will be achieved through expertise, passion and shared vision.
You could replace "Enterprise SOA" with just about anything and you'd be correct. The problem is that large organizations are filled with people who are non-experts who don't have passion and lack shared vision. It's that simple. Good SOA Governance makes the assumption that statistically, the average person in your organization is, well, average!
See:
http://pettiford.blogspot.com/2007/04/governance-is-not-answer.html
Tuesday, December 11, 2007
SDLC and Work Patterns
Nick Malick stumbled upon a real common misconception. In a recent blog post he mentioned that a SOA SDLC must be more iterative:
Here's the difference...
- SDLC focuses on the phases, activities and artifacts
- Work Patterns focus on the selection of phases, iterations and workflows
It's hard to describe but take a look at this and I think you'll see what I mean:
http://www.usdoj.gov/jmd/irm/lifecycle/table.htm
See section 13.2 for an example. I do agree that running a serial SOA SDLC is not a good thing. I was glad to see Nick mention User Experience. Usually, we'll talk about the Consumer SDLC and aligning it with the Service SDLC.
Good Stuff!
First, a comparison: Waterfall looks like this:What Nick is describing is the use of Work Patterns within an SDLC. It is common for people to accidentally combine these two distinct concepts.
Waterfall: Plan --> Envision --> Design --> Develop & Test --> Deploy
Agile: Plan --> Sprint --> Sprint --> (occasionally) Deploy --> Sprint --> Deploy
A SOA SDLC looks more like this:
Plan --> Sprint (Process and User Experience) --> Sprint (Process & Services) --> Deploy --> Sprint (P&UX) --> Sprint (P&S) --> Deploy
Here's the difference...
- SDLC focuses on the phases, activities and artifacts
- Work Patterns focus on the selection of phases, iterations and workflows
It's hard to describe but take a look at this and I think you'll see what I mean:
http://www.usdoj.gov/jmd/irm/lifecycle/table.htm
See section 13.2 for an example. I do agree that running a serial SOA SDLC is not a good thing. I was glad to see Nick mention User Experience. Usually, we'll talk about the Consumer SDLC and aligning it with the Service SDLC.
Good Stuff!
Monday, December 10, 2007
Ruby on Rails picks REST, will you?
Just out...
http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done
This is an interesting question: When do you have to use SOAP? or WSDL? The answer is that rarely do you "have" to use it. The two most common reasons for using it are
1. It's the corporate standard (someone tells you to)
2. You have some software that only speaks SOAP
I'm a fan of using the smallest amount of protocol to accomplish the job at hand. REST is about simplicity - simple to design, simple to consume. And simplicity introduces scalability of human consumers. That is, it doesn't require reading gobs of white papers on the subject to understand it.
The funny thing is I'm also a fan of protocol extensions. The big idea behind the WS-* stack was that it didn't require you to use all of the WS-* stuff at once; you were able to pick and choose the elements you needed. You could use the basic messaging stuff and throw in a bit of security. If you don't want security, don't use it. You need transactions, hell throw that in... What the REST approach seems to be telling the Web Services world is that even the light stack (WS-I Basic Profile) is too fat. And I agree.
Clearly, I'm not alone on this. Plenty of people have pointed figures at the WS-I and called them ugly names. However, I haven't picked up anything from the WS-I organization suggesting that they realize that their lightweight stack is too fat. Instead of working on an even slimmer profile (call it the WS-SuperLight Profile), they are adding new WS-Fat stuff to the mix. I can't make it any clearer than this: WS-* is dead unless they create a lighter weight protocol.
True RESTifarians will point out that REST isn't really about a 'lighter stack' but rather the genius of REST is in the tenets of the disertation. I mostly agree but I think that there are still variations of the tenets that need to be explored. For example, some might argue that if a new profile was created that Relax NG might be strongly considered as an element.
Regardless, it is clear to me that the WS-I is too fat and about to have a heart attack. But rather than going out and exercising, the leadership team seems devoted to going out and eating a couple pounds of cheese cake. WS-* will collapse if measures are not taken - and soon.
http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done
ActionWebService out, ActiveResource in
It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so. As a naturally extension of that, we’ve pulled ActionWebService from the default bundle. It’s only a gem install actionwebservice away, but it sends an important message none the less.
This is an interesting question: When do you have to use SOAP? or WSDL? The answer is that rarely do you "have" to use it. The two most common reasons for using it are
1. It's the corporate standard (someone tells you to)
2. You have some software that only speaks SOAP
I'm a fan of using the smallest amount of protocol to accomplish the job at hand. REST is about simplicity - simple to design, simple to consume. And simplicity introduces scalability of human consumers. That is, it doesn't require reading gobs of white papers on the subject to understand it.
The funny thing is I'm also a fan of protocol extensions. The big idea behind the WS-* stack was that it didn't require you to use all of the WS-* stuff at once; you were able to pick and choose the elements you needed. You could use the basic messaging stuff and throw in a bit of security. If you don't want security, don't use it. You need transactions, hell throw that in... What the REST approach seems to be telling the Web Services world is that even the light stack (WS-I Basic Profile) is too fat. And I agree.
Clearly, I'm not alone on this. Plenty of people have pointed figures at the WS-I and called them ugly names. However, I haven't picked up anything from the WS-I organization suggesting that they realize that their lightweight stack is too fat. Instead of working on an even slimmer profile (call it the WS-SuperLight Profile), they are adding new WS-Fat stuff to the mix. I can't make it any clearer than this: WS-* is dead unless they create a lighter weight protocol.
True RESTifarians will point out that REST isn't really about a 'lighter stack' but rather the genius of REST is in the tenets of the disertation. I mostly agree but I think that there are still variations of the tenets that need to be explored. For example, some might argue that if a new profile was created that Relax NG might be strongly considered as an element.
Regardless, it is clear to me that the WS-I is too fat and about to have a heart attack. But rather than going out and exercising, the leadership team seems devoted to going out and eating a couple pounds of cheese cake. WS-* will collapse if measures are not taken - and soon.
Saturday, December 08, 2007
The Next Phase of SOA
I've spent the last couple days at the Gartner Application Development and Integration Conference in Las Vegas. As you might guess, the majority of the show was really about Service Oriented Architecture.
Like many SOA events, there were plenty of sessions on SOA governance, strategy, quality and implementation technologies. New this year was a strong focus on Web 2.0 as the consumers of the services.
Despite all of the good sessions, there was a void around "Information Modeling for SOA". The process of analyzing and designing an information model that mimics the business is a huge issue at every client that I work with. Many of our clients have moved past the initial planning and setup phases of SOA and are out designing and building services. Companies are realizing that having pockets of service teams (working in silos) leads to a collision of service semantics.
Nick Gall, Gartner Guru, commented that this year everyone seemed to be on the same page. The vendors, consultants, analysts and buyers were all in agreement about the steps you take to roll out SOA, the kind of infrastructure you need, etc. In essence, we've been doing it long enough now that there are well known success patterns that are rarely disputed. Nick was also quick to point out that we're not home yet. Like me, Nick feels that Information Modeling for SOA remains a deadly issue for many organizations. Whew! I was so glad to hear that I wasn't alone out there.
He drew the analogy to the database world. Today, most I.T. savvy people know the basics about how to design databases. However, it is a much smaller number of people who are experts in database design - the kind of people who can tell you the difference between 4th normal form and Boyce-Codd normal form. In SOA, we lack the equivalent set of rules for modeling services. In SOA, most people don't even know the equivalent of 1st normal form. Guys like Thomas Erl have thrown out the basics of service design, but it is hardly enough to avoid the pitfalls.
And the issue is much larger than just designing a single loosely coupled service. The real issue is designing a portfolio of services without creating redundancies or conflicts in the message model. Imagine taking the message models of all of the services across a domain (or set of domains) and reconciling their semantics. This view is takes the service out of the 'semantic silo' and begins to introduce an enterprise vocabulary. And like all data, relationships will exist. Here is where it gets interesting. Many people have focused on 'decoupling clients and services' (which is great), but have completely forgotten about decoupling the data model (or service model if you prefer). Pull out a large ER-model and look at all of the relationships between tables. When you resurface the data models as business or data services those relationships will still exist.
The collection of services and their message models is what we call the Enterprise Service Model (ESM). The science of creating the ESM is centered around "Information Modeling for SOA". More to come on this...
Like many SOA events, there were plenty of sessions on SOA governance, strategy, quality and implementation technologies. New this year was a strong focus on Web 2.0 as the consumers of the services.
Despite all of the good sessions, there was a void around "Information Modeling for SOA". The process of analyzing and designing an information model that mimics the business is a huge issue at every client that I work with. Many of our clients have moved past the initial planning and setup phases of SOA and are out designing and building services. Companies are realizing that having pockets of service teams (working in silos) leads to a collision of service semantics.
Nick Gall, Gartner Guru, commented that this year everyone seemed to be on the same page. The vendors, consultants, analysts and buyers were all in agreement about the steps you take to roll out SOA, the kind of infrastructure you need, etc. In essence, we've been doing it long enough now that there are well known success patterns that are rarely disputed. Nick was also quick to point out that we're not home yet. Like me, Nick feels that Information Modeling for SOA remains a deadly issue for many organizations. Whew! I was so glad to hear that I wasn't alone out there.
He drew the analogy to the database world. Today, most I.T. savvy people know the basics about how to design databases. However, it is a much smaller number of people who are experts in database design - the kind of people who can tell you the difference between 4th normal form and Boyce-Codd normal form. In SOA, we lack the equivalent set of rules for modeling services. In SOA, most people don't even know the equivalent of 1st normal form. Guys like Thomas Erl have thrown out the basics of service design, but it is hardly enough to avoid the pitfalls.
And the issue is much larger than just designing a single loosely coupled service. The real issue is designing a portfolio of services without creating redundancies or conflicts in the message model. Imagine taking the message models of all of the services across a domain (or set of domains) and reconciling their semantics. This view is takes the service out of the 'semantic silo' and begins to introduce an enterprise vocabulary. And like all data, relationships will exist. Here is where it gets interesting. Many people have focused on 'decoupling clients and services' (which is great), but have completely forgotten about decoupling the data model (or service model if you prefer). Pull out a large ER-model and look at all of the relationships between tables. When you resurface the data models as business or data services those relationships will still exist.
The collection of services and their message models is what we call the Enterprise Service Model (ESM). The science of creating the ESM is centered around "Information Modeling for SOA". More to come on this...
Subscribe to:
Posts (Atom)