Amazon and Yahoo's 'SOA offerings' and the applicability to Government space

This weekend a colleague compiled an overview of some recent cool offerings from Yahoo and Amazon, with a challenge to learn how to help the DoD learn from these offerings to better execute major technology transformation programs such as
NCES.

NCES will provide Department of Defense (DoD) organizations ubiquitous access to reliable, decision-quality information through a net-based services infrastructure and applications to bridge real-time and near-real-time communities of interest (COI). NCES will empower the edge user to pull information from any available source, with minimal latency, to support the mission. Its capabilities will allow GIG users to task, post, process, use, store, manage and protect information resources on demand for warriors, policy makers and support personnel.

It really is quite interesting to see the parallels between what some big industry players are doing with their service infrastructure capabilities and the objectives of the DoD's Core Service Portfolio. While these are all some cool technology capabilities; the key is how they provide a flexible and adaptive base for some truly unique business offerings - which is why Amazon and Yahoo are putting them together and offering them. Now that we are beginning to see the tools to execute on the "Web 2.0" vision, I think its time to really go outside the traditional comfort zone of technology for simply obvious coolness factor and really try to understand how it apply to the value space. I'd ask how to articulate the business value proposition is for these capabilities - and what short-term or long-term ROI are the companies looking to reap? I started to look a little bit at the current business models of Amazon and Yahoo to pinpoint the role of rolling out these services to the general public. I came across the following article in business week that is quite related:

"Wow, the news is all about shifting paradigms and changing models, with Apple and Amazon seriously beginning to sell movie downloading services and Ford seriously beginning to get serious about remaking itself into a 21st century auto company."

A bit further down in the article is a link to another business week article (thank goodness for blogging, track-backs and other cool technologies that allow us to navigate and build upon the connections in information across the web that others have made for us.) I saw the following:

"It is increasingly important for managers and designers to go outside their traditional paradigms and structures to learn about innovation and poker--yes poker-- may provide useful insight. Thanks to a four part series called "Upping the Ante: Understanding business & design through casino poker" by Dirk Knemeyer, founding principal of Involution Studios, the tactics and strategies of this booming game are now revealed.

The first part of the series is about knowing who is playing in your competitive space. Knowing your poker opponent, really knowing the person, means winning or losing. Superficial understanding won't do. In like fashion, knowing your consumer, deeply knowing your consumer in an intimate manner, also means winning or losing. Accepting superficial, market research-generated generalities about their personas, could lead companies to lose their game."

What I take from this is the following:

1. To achieve the objectives of a shifting paradigm and changing model - including the technology innovation to support - it has to be taken seriously. Not only within individual programs, but across the DoD. This means business as usual will NOT be acceptable. Despite the creation of several transformational programs, the way that the DoD does business and acquires capabilities must also be taken into consideration.


2. Understand the players - deeply and intimately. Do we understand who would want to weave business capabilities together in the DoD? What are their needs that aren't being met - that can be achieved through this type of model? How does this model change the incentives (and power structure) through which things get done across the DoD? What message are they looking to hear apart from a technology perspective? How does this message translate into technology?


3. How can/should we accommodate the differences between Amazon & Yahoo and the DoD - both from a mindset, from an operating model, from a financial model, from a market offering and the value proposition to its customers? Who do we consider the customers of the DoD - and what are we offering them? Can the transformation that we're looking to execute through technology really occur without the DoD 'getting serious' about the operating model? Finally, what 'bets are off in the DoD' that are perfectly valid and appropriate assumptions in the commercial world?

I think this technology is fantastic - and it represents incredible strides in the bottoms-up capabilities that are helping to drive evolution toward a service oriented enterprise. Of course, Amazon and Yahoo see a business value in offering these services - and aren't just offering them (I don't believe) for the good of developer/customer-kind. They do or will drive revenue and profit, which is how shareholder value is created - and the measuring stick by which the success will be measured. If it truly is a coolness factor, we need to remember that Amazon and Yahoo most likely have that factored into their strategy as a component or driver, but not the end result.

We also should remember that transformation is also about top-down understanding. The top-down between commercial and govt (esp. military) entities is significant - and we are uniquely positioned to identify and address these differences. So my challenge to all of us would be to identify really what is the applicability of this type of technology to the business model of the government. In particular, what is the actual market offering - and why will the targeted customers bite? AND, how does the financial model support it? Traditional tools and metrics that can be used for Amazon & Yahoo just don't apply as nicely in the public sector, but that doesn't mean that a value proposition isn't there. It just has to be expressed differently.

Data Services, DRM and SOA

My perspective on SOA is unabashedly not strictly technical. It is also business and conceptual. These days, I am finding that most 'technical' issues have the dual nature of technical/business or need/capability. We attacked this head on in the SOA-RM - and that we continue to see this pattern apply and remain valid is a testament to the work.

The most recent example is related to Digital Rights Management:

I'm working with a group of colleagues to explore the chartering of an OASIS TC to collect, analyze and document the requirements and patterns for data management and sharing in a networked environment where data services lie under different domains of ownership and stewardship. One of the topics that we're working through is what role Digital Rights Management (DRM) should play in this solution. Matt Mackenzie suggested that we consider the perspectives expressed by Steve Jobs. What comes through loud and clear from his letter is the reality that challenges of DRM are not solely technical. The business model of the Big Four requires a complex technical DRM solution from music stores - but I see essentially a conflict between business models between them and companies like Apple. Within the data services discussion, we are looking at a technical interoperability solution, but I remain unclear whether we run risk of over-complicating business and policy issues by trying to solve them only with technical tools and almost oblivious to non-technical solutions. That said, while a technical TC isn't the right forum to solve these business level issues, I don't know what would be the right place to address those issues.

We're back again to the alignment of technology to business objectives. It is left unspecified how it is possible align technology when business objectives conflict =)

No pun intended....but I feel like a broken record.

Do we really need SOA?

I've been a little less than enthused about all things SOA as of late....mainly because it seems like it is as easy to sell SOA as it is to sell snake oil, or magic diet pills, or a plan to get rick quick by investing in real estate foreclosures. Obviously, there is some pain that the fundamentals of SOA address. But, a solution system is service oriented by its very nature REGARDLESS of whether or not it was touted as SOA. It just is!

Consider the following: SOA is about aligning technology - including the IT infrastructure and the application portfolio - with business objectives. It isn't about standardized interfaces or making applications interoperable as *the* *primary* objective. Rather the objectives are to use IT as a tool to solve business challenges.

To solve these business challenges, we need:

• To increase speed of response of IT to the demands of business


• To lower development, integration and support costs


• To improve usability of applications, websites and portals


• To provide faster access to high quality information and IT services


• To support more timely, and better informed, decision making


• To automate standard processes, improve performance, quality and controls

The best practices of SOA enable these results. Things like:

• Reduced integration complexity through abstraction and standardized interfaces, which
  
  
  
  • Increases the ability to scale around defined service functions
  
  
  • Enables multiple access and delivery channels
  
  
  • Increases flexibility to address business change through component-based applications
  
  
• Normalized infrastructure and IT services, which
  
  
  
  • Positions applications and tools within the IT portfolio
  
  
  • Decouple application and business logic in the future architecture
  
  
  • Increases flexibility to address business change through component-based applications
  
  


• Commoditizes non-core IT capabilities
  
  
  
  • Minimizes costs to maintain multiple technologies and platforms, which
  
  
  • Reduces technology “free for all” and religious wars around technology decisions
  
  
  • Decreases time to complete of change requests
  
  
  
  

Just my thoughts.

Everware-CBDi Industry Analysis Report "In Search of a Common SOA Language": What is a Reference Model?

A few days ago, the January 2007 version of the CBDi journal dropped into my email inbox. This issue analyzed the Reference Model Landscape - including architectures, profiles and meta-models.

Let me be clear, the article does a good job of comparing various efforts that purport to be a reference model for SOA. There are a few key points of analysis with which I disagree. While I have a few moments of time over the next few days, I'd like to share my thoughts on these points of disagreement.

The SOA Reference Model is not a Reference Architecture

It was likely necessary to extend the boundary of analysis to reference architectures and meta-models so to identify enough efforts for a broad comparison. However,

A reference model is an abstract framework for understanding significant relationships among the entities of some environment. A reference model enables the development of specific reference (or concrete) architectures

The report posits that "the OASIS model, while adopted as a standard, is a rather fuzzy 'reference architecture' with many of the concepts deemed necessary by the authors of this article left clear or undefined."

Attempting to compare the relative merits of reference model with reference architectures is like trying to compare apples and carrots. With this analogy, we can compare the qualities of fruit vs. vegetables or the specific characteristics each food item. However, building a comparison of the relative strengths and weakness of each does not consider when the differences are intentional and appropriate.

Comments on Everware-CBDi Industry Analysis Report on "In Search of a Common SOA Language"

I receive the monthly newsletter from CBDi and usually find much useful and insightful information. I was disappointed to receive this month's newsletter with the following headline "in Search of a Common SOA Language." The article starts out with "we believe that a widely accepted reference model for SOA will accelerate the take up of SOA, since tool vendors and practitioners will have a more solid and common base to work from."

As part of the reference model landscape, the following sources were analyzed:
W3C Web Services Architecture
OASIS SOA-Reference Model
IBM UML 2.0 Profile for Software Services
OpenGroup Open SOA Ontology
UK Ministry of Defence Ministry of Defence Architectural Framework Metamodel
Everware-CBDi "A Meta Model for Service Architecture and Engineering"

I'm working through the article in a bit more depth today....but would welcome a discussion on this list on the validity of the strengths and weaknesses that were identified.


The full article can be found at: http://www.cbdiforum.com/bronze/journal/2007-01/in_search_common_soa_language.php

Hit in the pocketbook, governance and budget priorities

Found some notes from earlier this summer from some blog reading...I can no longer find the original reference...so if anyone can help me track down the original so I can attribute....

However, while these notes were originally captured because of their relevance to service granularity; they also suggest the some of the responsibilities of the enterprise from a SOA governance perspective.

"Some who have started down the SOA route have soon found that coming up with popular services that expose data – previously hidden away behind obscure stored procedures and SQL requests – hits the wrong departments in the budget. Services often prove to be too popular – and the people who like them are not, necessarily, the ones who have to foot the bill for them."

Is this indicative of a service approach that is overly granular? If these services are really functions, then yes, this is a problem at the outset. However, services should really be aligned and defined by business/mission functions. Perhaps this burden of popularity is really good market research that indicates where there is a competitive competency that is waiting to burst out from the organization who pulls the data together.

First, to note that the organization suggested by this 'burden of popularity' might not be the office who owns the data. Rather it is the data steward or the office that puts enough together to create value with the data.

From another perspective, it sounds as though there is a missing element in this scenario in which there is no clear understanding or organization of capabilities within the organization. Perhaps the switch to services, which reduce the barriers to interacting with services through standard interfaces and detailed specifications, is only emphasizing what is broken in the organization. This seems to resonate with me. It isn't that the technology is broken. Rather it magnifies problems, or lack of awareness, that exists in the organization already.

If individual groups offer services to other parts of the organization, they have to get away from the idea of throwing services out and seeing what happens. Experts in this area all insist that SOA needs an architectural overview in the first place. And it needs to commit to service delivery and financing that genuinely looks at departments or groups as providers of actual services, rather than lumps of code that happen to have been tagged with the name ‘service’...You need to educate people about what it means to expose services and look at the commitment it needs. Commitments have cost implications. Where you see that happening it has a more positive effect on IT in how it is governed

I think the distinction come into even clearer focus if we talk about brick and mortar capabilities. You don't just throw out retail products to 'see how they'll do', you don't just 'start focusing on a market segment without a well thought out strategy for addressing the needs of that market segment and a understanding of how the core competencies of the organization provide values to those customers.

Getting SOA done through governance...

According to the SOA-RM, the central focus of service-oriented architecture is getting something done at a business level. In fact, Michael Poulin recently published an excellent article to explore this theme.

Considering the SOA Reference Model
...The function is something the organization cannot exist without; the organization business model is the combination of such functions while the actual implementation of the function is the secondary category. Unfortunately, up 'til now, the majority of IT applications fit exactly into that category. Now SOA creates an opportunity for IT to become the business partner and perform as a function for its enterprise rather than just a support provider

The article rightly points out that the partnership between business and IT is a crucial aspect of a successful SOA. The same goes for SOA governance. This is a key point that Eric Marks and Michael Bell's emphasize in their discussion of governance in "Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology."

Technology products, such as a UDDI registry, are the tools which enable a governance processes that fit the organization. The governance processes, frameworks, and policies defined by the enterprise determine the fit to be achieved. Technology, once again, serves as a key enabler, but ultimately should not define the SOA governance model.

Authoritative Services and the Money-Back Guarantee...

Earlier this evening, I came across Todd Biske's discussion on Choosing Appropriate SOA Governance. In it, he stated:

"...In addition to figuring out what SOA means to your company, you also need to figure out what SOA Governance means to your company. Should you be progressive about governance and focus on cutting edge concerns, or do you still need to cover the basics? What information do you need to provide as part of the governance process, and how much do you involve the people who will ultimately be governed by the policies being set? Ultimately, success will largely depend on how well your approach to these topics match your corporate culture."

How true. SOA is about aligning technology with business objectives. Managing this alignment must remain in harmony with the organization defining those objectives. Therefore, if an organization is built on a Command and Control Management style, governance is more likely to focus on ensuring only the 'right' services are made available by the appropriate service providers rather than waiting for market forces (survival of the fittest) to determine which services should remain. The governance policies appropriate to this type of organization would be heavily design and publication-oriented - and focused on preventing unsanctioned services from being offered. Emphasizing runtime policies in a SOA governance plan for this organization would run counter to the organization's strategies, objectives and processes.

The objective of any SOA governance plan to create an orderly information marketplace. Of course this includes a definition of what constitutes an orderly information marketplace, but I digress. Therefore, implementing SOA governance is about organizational savvy as much as it is about understanding the technical nuts and bolts of implementation.

As I wrote the paragraph, I mentally slapped my head - because it is glaringly obvious that SOA governance is equally about the organization as it is about the technology.

On a side note, I believe that understanding the management style of an organization also provides some insights into how it will approach its service portfolio, its service funding model and eventually settle upon a SOA reference architecture. I'll plan to work on this thread a bit more, but as an initial thought:

A Command and Control Organization will seek to designate 'authoritative services' as the way to control the risk of poor information quality in the enterprise. It also provides some interesting insight into what entities are considered capable of managing risk and suggests some business & technical principles that will drive SOA initiatives within the organization:

1. Providers of a services are emphasized about potential consumers of a services (and likely will reflect in the enteprise service funding model), and therefore
   
2. The primary responsibilities for data quality is assumed by the service provider (rather than caveat emptor), and therefore
   
3. The consumer assumes risk only of correctly authenticating the identity of the service provider (which sugggests that information is not quite considered a first-class object ).

I also need to think about the implications of these statements on the two-sided services market (see Harvard Business Review , October 2006 issue) that is inherent in SOA.