Tuesday, June 24, 2008
Those of you in IT management, who are negotiating contracts with outsourcers, you must make sure there is enough flexibility in the contract to accommodate appropriate monitoring, troubleshooting to handle shared services environment. The other option is have your employee augment the gaps to make sure your SOA infrastructure is operating smoothly.
It is important to do this in the context of the Services Life Cycle and did publish a short presentation on this topic a couple of months back. This presentations is a summary of the SOA Practitioners Guide Part 3: Introduction to Services Life Cycle with the addition of the IT Engagement Model slide (14) shown below.
This is the RACI (Responsible, Accountable, Consulted and Informed) slide listing all the roles and responsiblities of various actors across the services lifecycle. This is pretty generic in nature and could also be applied to non-SOA lifecycles too.
You comments are always welcome and do feel free to drop me line.
- Yogish Pai
Monday, June 23, 2008
Wikipedia definition starts with "SOA is a software architecture...." and because of this, I would not agree with it. Maybe one of these days I shall get enough courage to change it on Wikipedia :) .
I just read Surekha's blog on Key Best Practices: What is Serivces-Orientation? and am in complete agreement with her that
There is no place for the use of architecture terms, technological jargon or even as much as a mention of the web services or the WS-* stack in this definition!!
I would still define SOA as described in the SOA Practitioners Guide Part 1: Why Services-Oriented Architecture? . The SOA Practitioners defined it as follows:
SOA is a business operations strategy for leveraging information to meet the organization’s objectives, such as increasing overall revenue, boosting customer satisfaction, improving product quality, and enhancing operational agility.
Following are the reasons why this still makes sense to me:
First: Business is responsible for their own strategy (some interesting anecdotes) and yes! IT should (note: not MUST - IMO) have a seat at the table to help influence the strategy. Once the business stategy is established it is the responsibility of Business Operations to execute on the strategy. This is where IT comes in - parnering closely with Business Operations in developing the Business Architecture. People from the IT Organizations generally interact with Business Operations on a day-to-day basis. The IT Leadership does interact with the business executives but more on a periodic basis. It is for this reason I prefer the term SOA is a Business Operations strategy for leveraging information.
Next: I like all strategies to be actionable, i.e. a roadmap for achieving specific desired goals. For example, the primary goal for SalesForce.com (Disclaimer: I know as much about SalesFoce as most of the readers of this blog) is to most probably to become the primary platform for ALL SaaS solutions in the market. In this case, the business operations folks (sales, services, marketing, finance and IT) have most probably defined approaches for meeting this objective (which could be in form of marketing campaigns, events, sales incentives, partner programs, etc.). In order to execute this strategy they will require services from their own internal IT (yes! they do have an IT Organization) to provide them the capability to execute and monitor the progress (...leveraging information to meet their objectives).
Finally: I agree Todd's and Rob's thoughts about the term "The Business" - my observation is that this is not limited to IT Organizations. This is true for all organizations where I have heard sales executives refer to the "Those Marketing Operations folks" and so on. The only company where I had seen systematic approach by executives to rediret the entire company to consider themselves as a single team was at The Coca-Cola Company (or at least that was my observation in the early 90's - when I was in their IT organization). So even though I agree with their frustration with the term "the business" - I still prefer the term Business Operations in the definition.
Hope this was interesting and do drop me line to discuss this further, if interested.
- Yogish Pai
What is Service Orientation?
- It is the ability to use of simple business syntax for defining and discovering business services whose interfaces encode business behavior using the business language
- It is the ability to define a business service policy that governs the avaialbilty and reliability aspects of the business service
Service Orientation most of all is about the use of simple business terms defining business offerings that execute business capabilities. There is no place for the use of architecture terms, technological jargon or even as much as a mention of the web services or the WS-* stack in this definition!! The need for web service standards, SOA infrastructures technical stacks including HTTP, URIs or SOAP/ HTTP and WSDL enter the picture only when talking about the how to achieve Service Orientation, not the what is Service Orientation!
The technology is undoubtedly important provided an enterprise has the discipline of Business Architecture in place to define its' business service portfolio. In addition to this, the business service portfolio represents an enterprise' unique interpretation of Service Orientation and this enables the enterprise to deliver the strategic capabilities that are sought by the business. These strategic business capabilities are delivered as business service offerings that lead to market differentiation opportunities.
Without undertaking an effort to leverage in the Business Architecture discipline an enterprise has IT investments in technology of ESBs, the Service Registry and Service Repository etc. but the Web Services that are published look more like API calls. These API like web service interfaces will befuddle the business and will not help the enterprise realize the full potential of "Service Orientation". As would be noticed Service Orientation is built right into the concept of Service Oriented Architecture (SOA).
WOA and SOA are both architecture models that speak to the implementation models for achieving "Service Orientation".
WOA is a way of taking the REST-like service interface concepts that involve the invocation of standard operations that act upon simple payload identifiers and are transmitted over standardized internet protocols. The WOA paradigm embeds complexity in the "message format" or the payload. In other words, WOA prescribes a clean architecture model that enables an enterprise to quickly expose services with information constructs represented as URIs (instead of complex XML Schemas). Furthermore, the interfaces are defined as simple HTTP commands of "GET, POST, PUT and DELETE". It must be reiterated that the key point of the WOA model is to abstracted away complexity behind the simple interfaces and URIs. This aspect of simplifying the interface is very much in keeping with one of the principles of Service Orientation. However, this model may not really meet the other tenet of Service Orientation i.e. interfaces are represented using business vocabulary and are codified using business syntax.
SOA on the other hand is an architecture paradigm that leverages a more complex message format (that is defined as XML Schemas) with the interface definition that is could be deemed more business-like. Here the complexity of the message construct is codified using XML Schemas. These XML Schemas encode the business-document structural rules but do not expose the complexity of the business rules. So to some extent SOA meets the other Service Orientation tenant in keeping service interface definitions more business-like long as the interface definitions are driven by business architecture process.
WOA or SOA do not by themselves address the governance and monitoring of the business service policy. SOA infrastructure is needed to address service policy monitoring, service clustering and scalability concerns. In addition, the use of service infrastructure components such as ESB service-mediation flows enables IT to achieve location transparancy of business services that indirectly influence business service availability. It must be remembered that SOA infrastructure products are important to the business only in that they help meet the business’ service availability needs.
Just because the business does not need to be exposed to the implementation details does not mean that IT has the luxury of glossing over how the enterprise deals with transaction management rules and the incorporation of the ever changing regulatory business rules. It is just that these complexitites are left up to the technical and operations experts in the IT area.
An important aspect in talking about the maturity of SOA based technologies is that most commercial SOA infrastructure component vendors are striving to comply with the WS-* standards. This level of standardization promotes interoperability of the SOA based infrastructure components even when purchased from multiple vendors. The effect of this interoperability is that it finally affords IT a chance to now purchase packages to implement these complex implementation behaviors (such as transaction managment, service monitoring, service management and deployment, regulatory and security business rule interception etc.) as opposed to having to implement these complex implementation behaviors from ground-up. Now IT has a way of aligning its' business serivce delivery model to achieve the business need at the speed of the business instead of having to deal with infrastructure and integration issues.
Whether a WOA model or a SOA model is used to define and deliver the business capability to the business does not impact the concept of Service Orientation. The use of the WOA/ SOA constructs do not add a competitive business edge. They are just best practice architecture models that add to the reliablility of the service delivery aspect.
Your feedback is invaluable.
Wednesday, June 18, 2008
A commercial web site that is interactive or an eCom solution that offers exciting end-user experience, personalization and one that promotes end-user participation is considered to be very successful in translating this level of participation into "sales" as it influeces the end-users purchase decisions.
Commerse sites such as EBay, Amazon etc. have had much success in this regard. Some of the high level benefits of carefully employing these sets of Web 2.0 technologies may be listed as follows:
1. Use end-user product reviews to suggest alternative product usage ideas that can be used for marketing campaigns. These could be used to cross-sell and up-sell other related products and accessories on the syndicated and partner sites as well.
2. Increase customer participation and level of interest by actively seeking opinions on products or even increase customer satisfaction by polling for ideas of improvement. These comments and feedback are then available to customer support and to marketing personnel.
3. Leverage other blogs and wikis for word of mouth testimonials on your products.
4. Provide customers with RSS feeds of promotional prices and new product introductions. Also, the same mechanism can be used to make product promotional information available to syndicated web sites and other partner sites to realize cross-sell and up-sell oppurtunities. Alternatively, one can use a competitors' RSS feed to "subscribe" to these types of promotional events whereby this information could be used to alter one's own pricing and promotional model.
5. Leverage the reviews and market research thoughts from consumers to obtain new product ideas and end-user reaction to potential new product ideas.
As can be seen much can be done using the Web 2.0 paradigm to increase sales oppurtunities, improve customer satisfaction and to influence consumer purchase decisions. In addition, in some cases "knowledgable" customers actually increase chances of success in introducing a technologically advanced product and may in turn positively impact the purchase/repurchase behavior of others as well.
Thank you for your feedback.
Tuesday, June 17, 2008
Saturday, June 14, 2008
However, Web 2.0 is more about the philosophy of having end-user involvement in the content of the site rather than the technology that drives it. Web 2.0 is not just a way to deliver rich look and feel passively to the users, as was in the case of the first wave of web applications. It is about end-user driven content and end-user driven ideas being provisioned on to the web site. This is a transformation from content-push model (from a content provider) to that of a content-pull and poll model. Web 2.0 is all driven by end-users and revolves around the end-users where in the published content is influenced by the consumers of the content.
Web 2.0 is about collective or community intelligence. It ranges from consumers making searches more meaningful for the entire community to allowing them to share their thoughts, expertise and even their personal experiences on the web‼ I attempt to highlight just a few of these concepts in this blog.
Index based collaborative search engines are a key component of this next generation web technologies. Search keywords and requests submitted by the end-users result in keyword-content correlation tags, indexes and other numeric metadata being associated with the content to improve the quality of searches. Each click related to the search keyword, adds a measure of relevance to a web page thus making the targeted web page content a more accurate source of information. This optimizes search relevance for all subsequent searches by other end-users.
Wiki – another Web 2.0 phenomenon, where by any end-users can edit the published content directly on the web site making the site content “dynamic”. This very facet of Web 2.0 has resulted in Wikipedia becoming the largest on-line encyclopedia. This feature also makes Web 2.0 a powerful “content” push engine instead of the passive pull model employed by the Web technologies of the first wave. RSS-aware programs can now surface and expose changes made to any of the Wikipedia sites based on end-user subscription for change notifications.
RSS syndication is also used by web-loggers (bloggers) and other news sharing content sites on the Web. RSS-aware programs called news aggregators are popular in the blogger community as they serve to promote mind-sharing among audiences with similar interests.
In addition, this content formatter technology based on the RSS protocol allows commercial web sites to push promotional and marketing content to their customer base. Customers can also use this news aggregator feature to automatically get content change notifications and updates about specific merchandise categories, new product introductions etc. Consumers can also post product reviews that can be subscribed to by other shoppers. All of this promotes customer participation and adds to the “peer pressure” on customers for encouraging purchase decisions that result in the increasing sales opportunity.
As can be seen, Web 2.0 is much more than just technology, it is truly a phenomenon. Next time, we will discuss the impact of this phenomenon on commerce‼!
Thank you in advance for your feedback.
Thursday, June 12, 2008
In such situations the business process reflects the problems associated with the underlying technology, where data is not integrated and/or is of poor quality. Additionally, applications supporting the business process are inadequate. This might be a good opportunity to re-engineer the business process and not simply automate the manual steps. At the same time, the representation of business design (business architecture) must reflect the current state.
I think it is important to have a good understanding of the business events that initiate business processes and the outcome of the process. Capturing of business events and how a business reacts to such events should be an important component of any business architecture.
Wednesday, June 11, 2008
An area that I have not explored in the whitepaper is the usage of semantics to “discover” service offerings that are needed to deal with the "out of ordinary" alternate execution paths. It is true that today most of our processes are deterministic and follow a known or predetermined execution path. Any deviation from this deterministic execution path is typically handled by raising an exception or by routing the deviant information to a work flow component for human intervention. In future however, “runtime dynamic discovery” of services could be based on semantics that embed service ontology and process based state machine metadata - all of which work together in a business area to enable finding dynamic alternate execution paths that could be invoked to resolve “out of the ordinary” and exception situations.
As always your feedback on these thoughts and on the whitepaper content are invaluable.
Monday, June 09, 2008
In my opinion - even though the term Business Architecture may not have existed, some large enterprises as well as governments have been defining long-term strategic plans (Business Design) that adapts to change.
Lets take the example of Nokia - if you review their history one would be surprised to learn that Nokia was established in 1865 as a wood-pulp mill. Since then Nokia has been involved in many sectors, producing at one time or another paper products, bicycle and car tires, footwear (including Wellington boots), personal computers, communications cables, televisions, electricity capacitors, aluminium, etc. (Source: Wikipedia)
How did they go through this transformation? I did have an opportunity to partner very closely with Nokia during the dot com days and according to Nokia GAM, Nokia typically establishes a five year plan (Business Design) and executes to it. For example - once they determined that the PC business is going to be a commodity - they sold it and moved on to a new market segment. Looks like they adopted the Business Architecture approach established by the Soviet Union. History demonstrates that it did not work for the Soviet Union, but did work for Nokia. Maybe it had to do more with the market dynamics that the five year plan itself. The economy of India is also based on five year planning (the Soviet Influence) and the entire bureaucracy is measured against achieving this (and as usual the Politicians do interfere :) ).
Yes! it is very useful and great to publish the business design but not necessary for the market place. For example, Oracle which was known as a technology company is now viewed (by the industry) as an acquirer. IBM transformed itself into a Services Company but they still do have hardware and software. In this case the Business Design is essential to help define and explain the role of the hardware and software plays in it's services offerings. If not clearly defined (which includes the monetization aspect) one could land up as a niche players like Sybase and Sun.
These days there are lot of discussions going in various enterprises, forums, consortiums, enterprises and government organizations on topics such as:
- what is business architecture?
- where should it belong? (part of the EA team or business)
- what is the right place for EA? (shouldn't the CEO and the Board be involved in EA?)
Hope this was interesting and do drop me line to discuss this further, if interested.
- Yogish Pai
Saturday, June 07, 2008
Lets see what Oracles Executives have to say about this on the July 1st Web cast.
Friday, June 06, 2008
Following are a few of suggestions to the large ISVs (Independent Software Vendors).
The Platform is the application:
This is true and that a majority of IT organizations are demanding, starting right from the CIO down. This is true not only for enterprise solution but also for consumer solution, resulting in all major Internet (what do we call these companies now? ) companies such as Google, Yahoo!, Facebook, eBay and Amazon.com are taking this approach. For this discussion I shall limit it to the large Enterprise ISVs.
All the major ISVs have announced and invested heavily in developing their next generation application based on a unified middle ware. The message I am hearing from these vendors is that they will support the current version for quite a while (so if you have PeopleSoft 8.x you may be fine until Oracle decides to pull the plug) but they do expect you to upgrade (migrate - and yes! this cost you a bundle!!!!) to the next generation.
This approach really puts the IT organization (customers) in a spot, more so from people skills point of view. First, it will take time for the current staff (or SI partners) to come-up to speed with the new tools sets and second, the early adopter may pay the price to finding major bugs in the field, especially for their mission critical applications such as Finance, Order Management, Supply change, etc. Don't want to have major problems there. I would like to once again repeat that vendors need to incorporate SOA infrastructure in legacy application. If this does not work for them, they why not support the existing (legacy) applications from the next generation development ?
Lets take the case of an IT organization using PeopleSoft 8.x. Why not provide the PeopleSoft developer to developer to develop/modify existing work flow/application logic using their SOA Platform development tool? Agreed Oracle will have to invest in making this backward compatible for deploying the solution to PeopleSoft 8.x. However, this approach will get the existing support engineers up to speed on the latest tool resulting in faster adoption of the next generation platform.
End-to-End Life cycle Management:
Most ISVs, especially the large ones, do not provide an end-to-end life cycle management for their product stack(s). Of course, they will definitely claim that they do - but not really. How many software companies provide the capability for CIO and the IT leadership team keep track of all their major investments? also, how many of them provide the capability to get realistic feedback of the solutions deployed? None - as far as I know. Most of the Strategic IT organizations have been able to put this in place by procuring multiple solutions (IT Governance tools, EA tools, BPM, Enterprise Monitoring and Management Solutions, BI, etc.) and a lot of $$$ to stitch them together. Wouldn't it be great if the ISVs put something together that could be plugged in? Even if it just only for their solutions?
Provide Complete Solutions:
ISVs must provide complete solutions - not just point solutions that requires a lot of time and resources to customerise the solution. Lets take the case of Master Data Management (MDM) - all major vendors provide this solution (and one of them has 4 MDM products, including UCM) but is only a point solution. Why don't the ISVs integrate their MDM solutions with at least all their major (if not all) applications such as CRM, Order Management, Finance, Supply chain and Customer Support? Also, why not also provide the customer with a list of best practices and governance models (for free)?
It may may help if we all collectively push back on the large ISV and also have their Products Managers from ISVs spend 3 months in an IT Organization. Just a thought.
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differen...
One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed a...
It has been a while since I last blogged, especially after joining Intuit in 08-2008. For those not familiar with Intuit engineering cultur...