SO-uh-what?

How Might We Identify the Key Drivers for an Initiative

2008-06-14T10:43:00.003-06:00

I often read SOA strategy & planning discussed in terms of developing of a plan to build services that align to core competencies of the organization. When I unpack that statement, it reflects the same needs as the following: "The plan for individual initiatives should emerge in alignment with the key drivers of an initiative." So, I started wondering, what sort of guidance, tips or rules of thumb might be useful to identify key drivers for an initiative?

What triggered this train of thought:
Todd Biske's posts on Gartner AADI:

How does this relate to my work?
Regarding a session on Best Practices in Managing Change, the following statement resonated with me: "“The speed of technology deployment will not be gated by IT innovation, but rather by the ability to manage the people side of technology changes.”

That main me think; what should I ensure is explicitly addressed in the IT strategy & plan for a project - as a way to create synergies between the people side and technology side of changes that a project creates? I've pulled some of the recommendations out of the session notes and re-framed them as "How Might We" statements from the Creative Problem Solving Framework. This allows me to know apply the creative problem solving process skills to work through each of these dimensions. Therefore, the questions provides a checklist of areas to explore - and Creative Problem Solving provides the skills to systematically explore and address each of these areas.

What are the actionable guidelines/principles that I can apply in my work?

Remember and repeat its purpose (How might we communicate why are we changing)?

Explain the particulars (How might we describe what we are changing)?

Identify people that will need to change how they work (How might we outline who will be changing)?.

So, why should I care?
Well, frequently...our co-workers have a only a vague idea of why a project is important, and must trust that their activities are necessary and valuable. If the earliest planning activities made such goals clear and explicit, the execution will be smoother. When we veer off course or encounter an obstacle, these principles guide the decision making process with facts and accepted implications.

Putting together a Puzzle is Like Building a Capability Roadmap

2008-06-14T08:07:00.003-06:00

Last night, I had a bit of epiphany while I was putting together a puzzle with my husband. I became conscious of how I would approach the challenge of combining the different pieces of a puzzle into the picture of the Strip. (Note: We discovered that the written description on the bottom of the puzzle was different on the puzzle from what was displayed on the box front. Oops! Production error) Here's the rough order of steps that I observed myself making as I put together the puzzle:

(1) Scan the pile of pieces and identify two or three "theme"s by which some set of pieces can be separated out.

(2) Put all of the pieces that match a particular theme into a pile

(3) Select some way to organize the pieces in one pile (e.g. if you're working with the edge of a puzzle; put all of the straight-edged sides facing down)

(4) Pick some characteristic of the pieces by which to start matching pieces with their neighbors. For example; the Lines on the side of the Wynn became a charateristic that I could start to match up.

(5) If you hit a wall; find some other charactertistic and put a few more pieces together.

(6) If all else fails; pick a piece and then try to find its neighbor. Try all rotations of a piece to see if it fits as the neighbor.

(7) Repeat until puzzle is done.

It dawned on me that there is something to be learned about how to put together a capability roadmap. Its easy to state a methodology for building a roadmap. it is much more difficult to break that methodology down into a methodical set of best practices to implement the methodology. For example; most SOA methodologies specifies the need to "Identify all of your core capabilities." The questions that comes to mind are:
(1) What are some criteria to use to determine if something is core?
(2) How might we differentiate between a capability and an application/process?
(3) How might we identify which capabilities are needed but missing?
(4) If we discover multiple missing capabilities; in what order should we build them out?
(5) How might we determine different alternative execution plans to deliver capabilities at the right time?
(6) How might we determine when a capability should be replaced?

By finding the parallels in the challenge between building a capability roadmap and putting together a puzzle, I realized that I could find a way to apply the methods I used in the puzzle to making a plan to build a capability roadmap. For example, I can line up the questions I want to have answered and solve for each like I would putting together a group of like puzzle pieces. Then I can take those larger groups of pieces and put them together. This tactic worked EVEN IF I DIDN'T HAVE A PERFECT UNDERSTANDING OF THE FINAL PICTURE. Instead, I needed to identify some pattern in the pieces that would help me put them together.

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

2007-02-12T10:46:00.000-05:00

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:

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.

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?

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

2007-02-09T09:35:00.000-05:00

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?

2007-02-07T12:00:00.000-05:00

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?

2007-01-29T12:59:00.000-05:00

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"

2007-01-26T09:22:00.000-05:00

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

2007-01-13T19:09:00.001-05:00

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...

2007-01-04T14:48:00.000-05:00

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...

2007-01-04T00:32:00.000-05:00

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:

Providers of a services are emphasized about potential consumers of a services (and likely will reflect in the enteprise service funding model), and therefore
The primary responsibilities for data quality is assumed by the service provider (rather than caveat emptor), and therefore
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.

SOA and Governance -

2006-12-28T14:10:00.000-05:00

I've been working on the definition and implementation of a SOA governance as of late - and when you get right down to it, there isn't much new under the sun. That shouldn't be surprising, given that service oriented architecture is applying the concepts of commerce to technology. Here's my current thoughts (:

SOA Governance:

Define and execute the organizational policy and processes required to achieve business success of an SOA within SOA and IT processes.
Establish chains of responsibility, measurement, policy, standards and control mechanisms to exercise decision rights as part of the service life-cycle.

How does that become useful to a project manager that wants to know what to do - and how to create a consistent approach? Well, much of the work has already been done because SOA Governance concepts derive directly from traditional IT/Corporate governance processes and map into the SOA-RM. Now, the application of these processes may have a bit different flavor that traditional IT systems - because system boundaries are much more fluid and the emphasis is on dynamic interaction - rather than rigid definitions. So here's a working draft of the questions that a SOA governance process will address for a project manager.

Dynamics of Services –
Visibility:

How will others know that a service is offered?
What services are offered by others?
Who is authorized to offer services?

Interacting with Services:

What is the supported 'lifecycle' for services?
What metrics will be collected on the –ilities of a service?
Where will they be made accessible?
What levels of quality are required?
What are the requirements imposed on a service consumer?

Real World Effect: [I’m still working on this one]

About Services –
Service Description:

What elements must be contained in a service description?
What elements are change-controlled?
What is the process for CM?
What events require a new version of a service description be published?
What is the sustainment of older versions?

Policy:

At what stage of development is an SLA authored?
Where is it stored?
How will performance against the SLA be measured?
Who is responsible for measuring the quality of service?

Execution Context:

What are the key drivers for the initiative (e.g. reuse as much infrastructure as possible a la REST or build a WS-* infrastructure)?

*You'll notice that there are two distinct types of viewpoints embedded within this questions: CIO and Project Manager. The responsibilities and activities will vary significantly between these two viewpoints. However, they coalesce around several basic questions that must be addressed in any transition to a service-oriented environment.

Art, Science and Adaptability....

2006-07-17T19:59:00.000-06:00

Without discussing the morality of war, the concept of war bears many parallels to the concept of commerce. As the military seeks to learn lessons from private industry, remember that business tries to learn from great generals and strategists. Case in point, I'm reading 'The Art of War for Managers'. Therefore, it makes sense that there is much to learn on successful SOA from our military successes - and failures....I'll continue my train of thought on Lt. Gen Van Riper and Service Oriented Architecture (SOA).

War is about adapting. Any potential enemy as well as we, the United States, if we didn't adapt, learn, and evolve from our past experiences, we would be a species or a nation that would not survive. And any enemy that wants to survive against the United States can't fight like some of our recent enemies have, or they won't survive.

So what the heck does it mean to adapt through services? Well, one think that I think that it isn't is creating an entire system through traditional development lifecycles - including infrastructure, expectations, etc. Often, the the world is discussed in terms of 'phenomenon.' That is, when you put a whole bunch of things together that act independently, usually in their own best interests - and then let them interact - things don't always go as predicted....In fact, a 'phenomenon' often occurs. Sorta similar to how disruptive innovations that change some basic assumption previously held.

I'm trying to think of a good example and the best that comes to mind is human flight. As long as we tried to emulate the flight of a bird, no such luck. As soon as we adapted (within the rules of aerodynamics, etc), we started to make progress toward today's jet engines and beyond. This type of progress didn't happen by defining everything from the beginning and codifying all the assumptions.

Scientific rules became the interface into the world. As more was learned, those interfaces adapted...and the implementations, interactions and choreography based on those interactions adapted accordingly....but WITHIN their own time (hence acting independently).

Where am I going? Well, I hear alot talk and pitches about centralization and single point of whatever as part of your and I'm not really on the bandwagon that centralization is necessary. In fact, I will go further and state that centralization often leads to the desire for rigorous control over all aspects of the behavior that occurs through a system - which is a recipe for failure. Independent action leaks out all over the place. In technology, we call it a 'one-off' or 'point to point integration' or spaghetti code (well, not the only reason for spaghetti code, but I digress).

The bottom line is that we have to account for adaptability and one was to do that is to encourage and assume independent interaction (lots of reference here to other chapters in the books The wisdom of the crowd).

Whew...I never even got to my comments on a recent Zapthink Take....

The immutable nature of....

2006-07-17T19:16:00.000-06:00

I returned to work today from a six week leave of absence. The first week I spent in the hospital, recovering from pneumonia (I hope we never lose the drug barrier). That left me with a bunch of 'reading days.' I really enjoyed The Tipping Point by Malcolm Gladwell, so I asked my brother to bring his copy of Gladwell's latest book, Blink. There, among chapters on thin slicing, Cook County General, and Paul Ekman,there was a chaper that addressed the concept of net centric war-fare.

I found the discussion of the Milennium Challenge 2002 and Lt. Gen. Paul Van Riper quite fascinating. His approach to the challenge was, in many ways contradictory to the principles of the Joint Vision 2020 - which many people seem to cite as the underpinning of a SOA within the US DoD. I dug a little more and found an interview that Lt. Gen. Van Riper gave to NOVA. In this interview, Van Riper discusses the danger of placing too much faith in technology at the expense of a deeper understanding of the nature of war....

'We hear many terms, whether it's "transformation," "military technical revolution," "revolution of military affairs," all indicating something revolutionary has happened that's going to change warfare. Nothing has happened that's going to change the fundamental elements of war. The nature of war is immutable, though the character and form will change. The difficulty is that those who put forth this argument believe that something fundamentally has changed, and you can change very quickly without thinking your way through it. They want to apply the technology without the brainpower.'

We hear much ado from industry about how SOA will transform the way business happens. Sure much of this is really marketing-speak. (I recognize that promotion plays an important part of commerce, so this isn't a bashing on marketing). However, there is a certain belief that technology - particularly the latest and greatest - will transform/create a competitive edge/etc. So I started thinking, what can we learn from these observations about the fundamentally unchanging nature of war?

Basically, for me, it is intuitively obvious that SOA technologies are about changing the character and form of business - but the nature of business itself doesn't change. We specialize our capabilities. We find ways to add-value. We bring together supplier and demanders. We prove or disprove economic theories. Much like the nature of war itself doesn't change, the nature of business doesn't change either....therefore, SOA is about the form of business when effected through IT. Stated more simply, SOA is how manifest the business through supporting information technology.

So what else can we learn? The interview continues with "The first thing you have to understand is how you plan to fight in the future or in a particular engagement, a particular war. And once you understand how you're going to fight, then you bring the technology to it. If you lead with the technology, I think you're bound to make mistakes."

Great parallels! The application of SOA to a problem starts with the business. Here as well, we can learn from the seemingly boundless supply of military history and strategy. With a pure technology approach, we're bound to make mistakes....There isn't much of a bigger endorsement that I could imagine for a holistic approach to SOA.

When do Web Services Become a SOA?

2006-04-10T07:25:00.000-06:00

There has been a long discussion on the Federal CIO Council's SOA Community of Practice around SOA and Knowledge Management and how to actually put together a meaningful SOA demonstration. One of the (many) valuable pieces that is emerging from this discussion is:
How to differentiate between Web Services as yet another point to point integration tool/pattern and Web Services as a realization of SOA.

First, we're recognizing that SOA must ultimately address the challenges of information sharing. Ultimately, the technical dimensions of the problem are the easy ones. The harder ones (even) to understand are not technological at all. Rather, they are the very same challenges that must be faced every day, in every line of business. IT, in general, and SOA technologies, specific to this context, are no exception.

The challenges are:
COMMUNITY
*Dedication throughout a community to overcome challenges to information sharing.

GOVERNANCE
*Agreements upheld by all stakeholders to identify information and capabilities to share (exchange).

PRIVACY
*Sharing and dissemination protocols consistent with privacy laws and regulations impacting all participating agencies.

CULTURE
*Overcoming community and personnel concerns that prevent effective sharing.

TECHNOLOGY
*Leveraging existing technology to integrate knowledge, consistent with the established rules of governance.

LEGAL
*Navigate the various laws and regulations impacting dissemination of sensitive and/or case-specific information.

I would suggest that any services (thus Web Services also) expressed as part of SOA must exhibit several dimensions as part of a litmus test for determining when a collection of web services evolves from a collection to SOA.

The proposal currently on the table from Paul Prueitt (see the mailing list):

Web-services (expressed with a SOA) must have the following dimensions
1) re-use that is measured against community transparent utility functions
2) agility measured as the ability to respond in novel circumstances, and to novel requests
3) governance that is open to inspection from stakeholders
4) commonality within a community or community of communities
5) competency that is measured at several levels including competency

Too often we see existing systems or information being “service enabled” simply by generating WSDL from the existing code used to gain access to the information. One of the key challenges is to get folks to understand why that type of step != SOA. As a first step, perhaps a demonstration that web services which are in fact a realization of the technical aspects of SOA must exhibit these dimensions BECAUSE they address the challenges set out above:
COMMUNITY
*Dimension 4

GOVERNANCE
*Dimension 3

PRIVACY
*Dimension 5

CULTURE
*Dimension 4,5

TECHNOLOGY
*Dimension 1,2

LEGAL
*Dimension 3,5

Globalization?

2006-04-10T07:24:00.000-06:00

Here’s what’s fascinating to me – within relatively short order, the discussion of SOA and a particular demonstration of the applicability of SOA concepts to this context is not primarily focused on the technology aspects of the challenge. The same “lessons learned” will eventually be recognized in technology evolution, much as they are in cultural and societal evolution. While listening to an NPR newscast on globalization, I started thinking about how the characteristics of economic globalization may in fact also emerge in a truly service oriented technology system. Where do incentives come into play? What about middlemen, traders, brokers?

I posit that many, if not all, of the evolutionary patterns of the trading and economic system can be abstrated into the context of SOA.

Commentary on SOA Standards

2006-04-07T08:08:00.000-06:00

David Sprott (CBDi Forum) recently published commentary "On SOA Standards". I believe you need to be a member to access the full text of the editorial.

However,a couple of very relevant excerpts:
“...SOA is very different to most of the IT trends that come sweeping through our industry from time to time. First as an architectural concept SOA is not primarily technology driven, rather it is technology enabled. Second SOA adoption is inevitably situation specific because the needs of each enterprise are driven by the existing and future business and technology situation. Third the real impact of SOA will only be realized by most enterprises when a critical mass of content as reusable services is available either from internal sources or from enterprise application vendors such as SAP and Oracle.”

“The core principle of SOA is about standardization and reuse of common functionality in many different contexts, in a structure that is architected and engineered to be evolutionary and to have a managed level of adaptability.”

“In a very short time, probably less than one year...vendors will find a new focus for their marketing dollars. But in the real world enterprises, systems integrators and developers will be embracing SOA practices and techniques and building them into their kit bag because it makes sense.
• Architects and developers will use concepts of contractual separation and reuse because it makes sense.
• Enterprises and their suppliers will embrace SOA, progressively solving critical business problems in a better way than they might have done previously:
• Introducing core business services to enable consistent data and business policy,
• Using process services to separate the process and application layers, and
• Creating utility services to deliver very high levels of reuse across the enterprise.”

We're a long way from the days of the Captain Picard in the Starship Enterprise simply telling the computer "Access data banks" to get a perfectly relevant response. However, there is growing recognition that standardization, re-use, and business needs should drive technology rather than hype driving technology. As we continue to head in that direction, long after the the latest and greatest of SOA products are phased out of technology petting zoos and into technology archives, we'll get closer and closer to the ultimate objectives of SOA.

There's nothing new under the sun...but the rate at which we re-discover and discard things is changing.

2006-01-14T20:32:00.000-05:00

I was reading InfoWorld from January 9 and its discussion on High Performance Computing. One of the articles was about "Shipping company Con-Way [that] began its SOA journey eight years ago, providing one illustration of how the new architecture works for the long haul." One of the quotes from the article is that "the development team has to be very close to business." It reminded me of a discussion that I had about two weeks ago with one of my peers about how SOA applies the lessons of commerce to the delivery of IT.

What struck me was how quickly our change cycle is shortening. The idea that eight years is now the long haul is rather startling when you think about it. How long did it take for the computer itself to become integrated into the way we do business? How long did electricity (or any public utility) take, for that matter? Moreover, how long did it take for these things to be standardized.

Check out the "War of the Currents". It was only in 2005 that ConEd finally discontinued support for DC for its customer base in Manhattan that required DC for existing infrastructure like elevators.

What does that say about lifecycle and backwards compatibility? Certainly that support phase is much longer than most sunsetting technology products today.

2005-12-23T15:33:00.000-05:00

SOA is a fundamental shift from vertical to horizontal:

Was having a telephone conversation with a colleague today and the discussion was so good that I wanted to try to capture some thoughts we batted around for future pondering.

What impact does this shift bring? For example, it brings the SLA concept into mind because you have to htink about what has to go across rather than up and down. "I'm trying to use your thing not trying to build my own thing". How can you think about that at a mission level? Because a mission is built atop of or dependent to someone else's mission. Higher level capabilities are composed from other capabilities and value-add in the supply chain. This value-add can range from being strictly the combination of existing capabilities - i.e. bring together the three things that need to be combined in a single view - to bringing the knowledge/capability to bear to use all of those capabilities together in pursue of the mission objectives.

You have to think about the types of ways that people can use your capability/information. This is where the concept of SLA agreement comes into the play because it forces you to think about the flexibility that needs to be embodied in the interface so that data can be exposed as needed for a particular need as opposed to taking the fixed interface approach in which a data provider exposes data in one way and a potential consumer must take it as-is and filter through any portion of the data not needed for their particular purpose.

Metcalfe's Law and SOA

2005-12-20T10:44:00.000-05:00

More and more I'm finding parallels between the concepts of SOA and technical and business ideas. I was planning on posting some comments that I have on Neal Stephenson's excellent essay "In the Beginning was the Command Line". I was introduced to the essay through an internal presentation made here at my company by D. Calvin Andrus a week or so before I left for the Vienna FTF meeting of the SOA Reference Model. Here's the blog connection: in this presentation, he discussed Wiki and Blogs as a technology incarnation that supports continuous learning and adaptation and complexity theory. One of the slides had a screen shot from his own blog, from 5 January 2005. This particular post focused on Neal Stephenson's essay. I was intrigued enough to print out a copy to read on the airplane ride over the Atlantic. I have several notes on the content on links between his ideas and my own ideas on Service Oriented Architecture. However, now that 2 weeks have passed, I needed to go back to the presentation to find the actual URL to his blog. Along the way, I saw another slide in the presentation focused on Metcalfe's Law and Disruption. It was speaking more of the role of 'link creation' in the development of new intellectual capital, but it prompted me to find out some more about Metcalfe's Law and think about how it relates to SOA. Along the way, I found an article by George Glidder titled "Metcalfe's Law and Legacy". This article states Metcalfe's law of the telecosm shows the magic of interconnections. Glidder goes on to demonstrate the power of potential connections not only in technology terms, but also in economic terms - for personal wealth as well as the creation of additional wealth in the economy. What's also interesting though, is that Metcalfe himself recognized that "In other words, it is the stations, rather than the network, that have to sort out and "switch" the messages." It goes on to state that while the concept of a figurative ether survives in modern communications, there isn't a literal ether that exists omnipresently to propagate communications - and dive into a discussion of ethernet and ATM.

One of the ideas that resonates well with me is that SOA is really about applying the lessons learned from the history of commerce to technology. I'll have to talk about that more later. Essentially, that's why I really appreciate articles and information that recognize SOA as more than the next wave of technology. But what I've now also started thinking about is what we can learn from what we already know.

So, how do we recognize that SOA isn't just about the potential connections that can be made - but just as much about the 'stations' or the players in SOA and how they uuse the interconnections? What does it mean 'to be about' when we talk about SOA? Heh, that's a topic to mull over another day - but it seems initially to be about the value, emergence and mindset of SOA. There's a relationship there between people, process, and infrastructure with the technology, but none of them stand alone; just like the interconnections themselves don't stand alone - nor have value alone.

I have also started thinking about the A in SOA - architecture and wondering if the way that SOA is typically approached is 'treating the ether as literal'? How does it change the approach to system architecture and design of a distributed system when the connections (and hence the network) isn't robustly connected always present entity?

So, these are my thoughts today. Unbaked as they are, I want to follow them through at some point.

Successful SOA Reference Model meeting

2005-12-18T18:59:00.000-05:00

Last week, I headed over to Vienna Austria to work with the SOA Reference Model TC to hopefully polish the working draft of the specification sufficiently that we can make committee draft by early next year. From where we started earlier this year until now, there has been a tremendous amount of thinking that has gone into Service Oriented Architecture. One of the biggest points of improvement last week was a reorganization of the material related to services. In simple words, these sections correspond to "What You Need" and "What You Do." Effectively, these sections of the specification explicitly call out and address both a static as well as dynamic nature to the understanding of 'service.' Essentially, earlier debates on whether service is an action or an object are just another way of expressing this duality.

When we started thinking about things in terms of duality, it quickly becomes apparent that the duality of static/dynamic is not the only duality - need and capability; potential and actual; business and technology are other examples that emerge.

The last idea: SOA is about business and technology together, is one that seems to be gaining momentum in the industry. Recently, XML.org cited an IBM whitepaper titled "IBM's SOA Foundation: An Architectural Introduction and Overview" that states, "SOA is about the business results that can be achieved from having better alignment between the business and IT." I agree, almost. Earlier, the statement is made that SOA is about aligning business with IT to make both more effective. Certainly itrecognizes the synergy that comes from treating business and IT as a duality. However, we need to remember that, when it comes right down to it, IT is a tool. Having spent considerable amount of time trying to isolate why the nuances of a single word clouded my understanding, I'd suggest that we think instead about SOA as "aligning IT to business" rather than the other way around.

When trying to clearly express what is different about service oriented architecture, SOA if you will, this explicit recognition of dualities becomes a clear way to think about the differences in the approach - and it is encouraging that many in the industry are converging on this same recognition

Working toward the SOA Reference Model

2005-12-08T09:53:00.001-05:00

The SOA Reference Model TC is gearing up for the Face to Face meeting in Vienna Austria next week. The goal is to finalize the current working draft and elevate the draft to committee status by the end of the meeting. This is tremendous news because it means we are one step closer to a voluntary consensus standard that examines the key concepts and relationships between them for service oriented architecture - not product driven, not web service standards driven, not even software driven, but motivated to understand the essence of service and SOA.

I spent some time last night reading linguistic research to try and better understand what about the relationship between noun and verb forms of ‘service’ are sticking points for me. As I suspected; it has to with the implications about the relationships between these lexical forms. What was most interesting was to realize the variety of aspects to be considered. However, I think that I found what makes me want to tread careful and clearly understand and distinguish between service as a noun and service as a verb.

One of my colleagues, Chris Bashioum, used the wording 'the RM concept of service maps to a concrete "thing" called a service, that performs the action of bringing a desired capability to bear when invoked in the context of an SOA. This wording pointed out to me that there are two active portions of the ‘service scenario’:

1) That ‘of bringing a desired capability to bear’
2) That of the capability itself

Referring to a service as a concrete "thing" is essentially an abstract noun which performs the work of an active verb. Nominalization allows us write about a process or action and yet not mention who is involved. Again, this is part of the sticking point for me when it comes to a reference model in which we’re trying to unambiguously define key concepts – because we’re using terminology that permits us to unintentionally cloud the concepts when we are seeking clarity.

So I dug a bit further and discovered that there are many ‘types’ of nominalizations, including ‘episodic nominalizations.’ An episodic nominalization takes an active process and conceives it as a noun. So far so good, for service as both noun and verb. However, here’s where I found some interesting information about the intuition of language that is captured by these different forms. Although quite similar, these two forms represent adifferent semantics which conceptually develop. In an episodic nominalization, the conception is no longer viewed as a process but rather as a single episode (i.e. only as the sum rather than the sum of its parts). Yes this starts to get into cognitive psychology and linguistics ( and I apologize to those who just want to know what does the word service mean within the context of SOA but bear with me).

Where I got to is that yes, we may actually be talking about the same thing when we use service as an act and as an object - only we're looking at the concept from different angles. What I’m recognizing is that those angles come with specific inferences and assumptions that stem from language itself that we may not be explicitly aware of and which set up confusion.

So what am I saying? That the text in the draft works well to recognize that the term service(noun) unifies several related concepts – and we do it justice to recognize those interrelated concepts. Using the terminology above, they’re conceptualized into a single episode. If we are clear about that, then I’ll accept that a service can be intended as either.

The Definition of Service

2005-12-07T17:48:00.000-05:00

Recall the definition I provided for the term service:
* A service is the performance of work for others.

In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. I think it fair to say that some of these capabilities are core competencies. They might even create competitive advantages in the marketplace. SOA isn't fundamentally about creating new capabilities; it is about business services as the key organizing principles that drive the design of IT. What is the driver? Alignment with business needs.

So how does this tie back to definition of service? SOA is a way to organize the world around the concept of work performed for others. How is 'work' defined? By business needs. What world is organized? The performance of work, ostensibly implemented with IT assets. Notice I still express service as an act as opposed to an object. It is easy to think of a service as a thing (such as a web service). The difficulty with that approach is then differentiating between the capability (work performed) and the service. It also leaves unanswered chicken and egg questions like "if a service isn't invoked, does it exist" and "once interaction with a service is complete, does the service cease to exist" and " if there is no description of the service, is there a service"?

Ultimately, there are capabilities and there are needs. An example: let's say I have a catering company. You would like to have a dinner party catered. I offer my catering services for you. I perform the work of catering and you realize the benefit. The service is the act of me catering your party. I may describe the service beforehand in promotional materials (lets say); we most likely will negotiate and commit to a contract that establishs our shared expectations; and there will be an exchange of value - mostly likely because I will charge a fee for the service I offer.

Until I actually cater your dinner party, there is no service. There is potential for a service and an expectation of a service, but it boils down to the fact that the service is an act.

In general, my catering company offered a capability to serve or support a solution for someone else's problem. As such, I provide a service. My consumers have needs which may be satisfied by that capability.

Back the definition service within the context of SOA:

What I've seen and what I've read and what I've experienced is that service as a word is used as a unifier for the following related ideas:

1) The offer to perform work for others
2) The specification of the work offered for others
3) The software used as a tool to implement a capability performed for others
-as well as -
4) The performance of work for others

How do these other ideas relate to service?
1) The concept of an offer in inherent to a service. On a notional timeline, if work is performed for others, there must be an offer to do so. It may be formal, it may be informal, it may be explicit, it may be implicit, it may not follow a publish-find-bind paradigm of offer. But an offer must be made by some entity that will perform the work. In general terms, I would say that an offer is a proposal which is made by some entity may so to address a need.
2) A specification is a description of the work/capability. Remember the definition considers the act . Therefore, the description focuses on interfaces and behavior to support interaction between two entities: one with a capability and one with a need.
3) Here is where most definitions of service within SOA go. I don't disagree that this is an important aspect to consider. However, I think that terming this concept 'service' is wrong.

I pulled these thoughts together as I mused a question on one of my earlier posts on the SOA-RM mailing list. Here's the text of my email:

"We seem to be starting to head back to the service as an object as opposed to an act. I still do not believe that a service is an ‘object.’ In fact, I believe that assumption has caused much of the difficulty in figuring out what a service actually is.

What is invoked is a capability, consistent with the execution context and so to produce real world effects. The actual invocation and performance of the capability is the service; i.e. the action. Hence I maintain that visibility, interaction and effect are the interrelated concepts often (yet confusingly) referred to with a shorthand nomenclature of ‘service.’

As far as roles go, the very essence of the word service is the recognition that does for . I would agree that any other specification of this generalization (uh…isn’t that an ontology) belongs in something other than the RM. "

The question I received was: "What about defining service as the potential of an act? if I understand what you are saying here, it would imply that a service is not a service until it is actually performing an action. During the time that it is "waiting" to perform an action it is not a service, nor is it after it has completed the action it was created to do."

Right now, my best answer is: the implication is correct because is a service is an act, not an object, and we're again seeing a confuddling of ideas.

Ok. If anyone stumbles upon these initial posts, I'd love to hear addtional thoughts.

Initial Musing on SOA

2005-12-07T17:13:00.000-05:00

So I've finally transitioned to the world of public blogging. I've culled so many good ideas from others blogs and wanted so many times to capture my thoughts on things service-oriented (or otherwise oriented) that I decided it is time to pony and start my own blog also.

Earlier this year, I stumbled upon Kim Cameron's original postings on the laws of identity. The discussion and debate was truly amazing to watch evolve. I've seen lots of posts about service -oriented , but have only of late begun to see things creeping in the direction that I believe heads toward the true power of the SOA concept (age old it is true - this really isn't an IT revolution but an IT realization).

For those of you that have followed the many discussions on the SOA Reference Model email list; we've been working for awhile now to tease out the essential definition of SOA, service and core concepts (i.e. a Reference Model). We also do this where I work too.

My goal is to revisit and discuss the many facets of the fascinating topic of SOA and I hope to spark some additional debate and ideas that will help further clarify ideas related to all things SOA. So let me state, in this first post, my view of SOA.

Fundamentally, service oriented architecture is an architectural paradigm. I'll borrow liberally from IEEE to state "SOA is the fundamental organization of a system,embodied in its capabilities, their interactions and the environment so that IT assets are aligned to business needs."

As a technologist, I often want to define the world in terms of things technical. Hence, it at first seems natural to define SOA in terms of an information system (whether distributed, centralized or other). However, the system that SOA references is actually much larger - it is the enterprise itself. This means there are necessarily technical and non-technical components to SOA. What it implies is that the value of SOA comes not from a new technology push, nor from a business process re-engineering, but the combination of technology and business value. This really is nothing new, but the mechanisms to experiment with the power of this concept are more readily now than they were before.

One of the other reasons that I wanted to begin to record my thoughts on SOA were the often repeated email exchanges I have with colleagues regarding the definition for 'service.' I mean, if SOA is a service-oriented architecture, should we have consensus on what a service is? Here's what can really open a can of worms. I don't believe a service is a thing. A service is an act.

A service is the performance of work for someone else.

Such a short definition that goes so against what my background in software tells me. I propose that we're struggling to reach consensus on the definition of service because I believe that we're trying to reach consensus on the wrong thing.

I'll leave this first post with that as food for thought and return to this shortly.