How Might We Identify the Key Drivers for an Initiative

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?

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


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


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

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

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.