A Cellular Service company's SOA implementation

A leading Cellular network company in Israel, Partner Communications Company Ltd., provider of the Orange network in Israel, presented its SOA implementation in December 26th meeting of the SOA Forum of the Israeli Association of Information Processing.
I am moderating the forum since its imitation on March 2005. The forum meetings take place once in a month. The forum is opened for anyone involved or interested in SOA activities. Most of the meetings included presentations and discussions. The 16th meeting was exceptional: experts' panel on SOA Governance.

The presenter was Iddo Rachlewski (Infrastructure Applications Development Manager). Aharon Winder Partner's CTO, who joined us, answered the toughest questions asked by forum members.

Background
The Telecom service industry business model and technological infrastructure is changing due to Web based IP phone services, Wireless & Cellular communication and the need to transfer new types of data in addition to voice.
The trends may be summarized in the following highlights:

• Convergence of Telephony infrastructure and Information technology (IT) infrastructure. The new infrastructure is based on IP or Session Initiation Protocol (SIP).
  


• Multimedia content supplied by IMS (IP Multimedia Subsystem)
  New competition due to significantly lower costs for creating an infrastructure. Skype and Instant Messaging providers are examples of new competitors.
  


• Content based services as a new significant revenues source.
  

The traditional Telco services are the leading candidates for reduced revenues. , as result of this threat they are forced to innovate. SOA is a key innovation enabler.
The new Telco companies (e.g. cellular services companies) are relatively new companies therefore their computing environments are relatively new so the technical difficulties of SOA transformation are less severe in comparison to Banks, Insurance Companies and the traditional Telcom services providers. These companies should innovate and work more efficiently due to the increasing competition.
No wonder that Telephone suppliers sector is one of the leaders in SOA implementation including some successful implementations (e.g. Verizon, Sprint-Nextel).

Partner's Service Bus Implementation

Partner's implementation is named Information framework (IF).
It is a Service Bus. The SOA implementation includes other complementary components.

The following bullets highlight the key elements describing the Service Bus:

• Current version is based upon Tibco's EMS (JMS/RV) components with proprietary services developed in-house.
  


• The IF is an evolving framework. Current version is 5.1 in production since April 2006. The first version was entirely proprietary and originated in 2001.
  


• Approximately 400 services are using the IF
  
  
• The Bus supports Synchronous interaction (Send-Receive) and Asynchronous interaction (Send and afterwards Receive). Most of the interactions are Synchronous. Asynchronous services are used for multiple requests.
  

Service Bus Architecture
The following image, included in the presentation depicts the Enterprise Service Bus (ESB) architecture

• Every application (in-house Legacy applications, Oracle ERP, Oracle's Seibel CRM, Billing, oracle's Vantive, etc.) could consume and provide services via the Service Bus.
  
  


• Consumers interface is by proprietary Wrappers. For each service there is dedicated wrapper written in the same technology as the service (Java, DotNet's C#, COM, C, PL/SQL) Tibco BusinessWorks is also a Service provider and Service Consumer. A Wrapper is a collection of code libraries. An encrypted configuration file is also included in each Wrapper. The configuration file identifies the consumer.
  


• A SOAP interface and HTTP interface were added for standard based integration. Currently it is used by Application Packages using technologies for which no wrapper exists.
  


• The internal architecture of IF includes "Application Server", DB Server and Management Server.
  


• The DB Server includes two Oracle DB Engines. A proprietary mechanism is used for updating and synchronizing both databases. Oracle RAC was not an option when IF implemented due to unavailability or immaturity.
  


• The internal architecture of the "Application Server" includes: Service Broker (SRB), Dynamic Service Interface (DSI) and a Token Manager (TM).
  Service Broker is responsible for registering service consumer requests, parsing inbound and outgoing parameters (if needed).
  SRB transfers the request to DSI. A limited prioritization is achieved by deciding which DSI instance will take care of the Consumer request, based on Encrypted Configuration file identifying the Consumer.
  DSI pass the request to the Service Provider.
  The TM is responsible for workload control. In case of no available token the Consumer request waits until another Consumer request release its token upon completion.
  


• Management Server Components: Monitoring (Performance, Response Time, Load partially monitored by Tibco and in-house developed components and the information is passed to HP OpenView), Administration (e.g. defining new service), Statistics (by a Dashboard of Microsoft SQL Server 2005) and Logging (e.g. errors recording) connected to the company's central Log.
  
• Multiple instances of each component are Deployed in order to avoid Single Point of Failure and for Workload Balancing (additional instances invoking or suspension of instances is dynamic, with no need to stopping IF).
  


• Multiple Logical TEST environments are invoked in one Physical TEST environment by assigning different Configuration Files to different DSIs
  


• Transferring definitions from TEST environment to Production environment is by pressing single key.
  
  
  Other Components
  
• The process of defining new Service or changing a Service is based on a form filled by the applicant and approved by IF Administrator. It is possible to define relations between entities.
  The form is inserted in a company wide repository for asset management build in Visual Basic and Oracle database.
  


• Run Time Service definitions are part of IF. It is an application developed in JSP under Tomcat Web Server
  
  Limitations:
  


• Data feeds to both Repositories are manual
  


• Usually not all Service Users are registered in the Inventory (the first user identity is fed during service definition)
  
  My take:
  


• SOA is not a one time project it is a journey. Expect for a gradual evolution.
  In Partner's case the evolution is manifested by the large number of versions (approximately one version each year). Each version enhancing the previous by functionality and some versions also improve Scalability and Performance.
  Partner is planning architectural, technological and functional changes for next versions.
  The evolutionary journey is not unique to Partner. For example, Standard Life one of IBM's noted SOA success stories architecture was changes significantly during different stage of their SOA implementation.
  


• Leading Age is also Bleeding Age
  Early Adopters may not be able to use standard products because they were not mature enough. It is a trade off between gaining competitive advantage by using the new architecture versus more resources allocated for development and maintenance and a possible conversion to standard tools after they mature.
  In Partner's example planned next steps includes implementing additional Tibco's EMS components as well as a standard Repository or Registry.
  A known SOA Early Adopter is Credit Swiss, which deployed a CORBA based SOA in the 1990s. Credit Swiss is converting its Repository to a standard UDDI based and extended registry: Centrasite co-developed by Software AG and Fujitsu.
  


• The implementation is technical with no Business people involvement. One consequence is Technical Services instead of Business Services.
  The services granularity could be less coarse granularity then needed. Due to the low granularity the number of services is high; there is more Complexity and management overhead increased.
  More importantly, Business and IT alignment is limited.
  Partner is in the beginning of a process of deploying tools for supporting Business Services and possibly Business Processes. Currently a limited function of supporting Composite services (termed IFBL) is implemented. Expended IFBL functionality could enable definition of Business Services.
  


• The architecture is mainly SOA Integration architecture
  Mapping current applications functionality to Business SOA Services and gradually implementing Service Applications Architecture is an important missing part.
  


• Enterprise Wide Processes deployment support by current Partner's technology is limited
  Addressing this issue is a future direction planned by Partner.
  


• Application Server (in Partner If's terms) is an Integration Broker
  The term Application Server is not used for an infrastructure applications components container (e.g. IBM WebSphere, BEA WebLogic) but for Integration Broker). That the reason why I wrote "Application Server" and not Application Server in describing it.
  No wonder that Tibco tools were selected for SOA Integration, because Integration is Tibco's focus and strength. Tibco, the largest of the three EAI dedicated leading solutions (the other two WebMethods and SeeBeyond where acquired by other companies because of their SOA tools and capabilities) developed new generation of integration solutions which are SOA Integration tools and not a complete SOA framework.
  


• I suspect that Reuse rate is not high
  My first impression is that Reuse rate probably is not high due to lack of dedicated SOA Registry and due to low Services Granularity.
  


• Proprietary DB engine Fault Tolerance is not a preferred solution
  The tradeoffs between Oracle's RAC and the proprietary mechanism are more resources needed for maintaining the proprietary solution vs. the total independence between the two DB Engine instances in the proprietary solution. In my opinion database reliability is high and it will be higher in the future, so the trade off is in favor of the standard solution.
  


• Despite the Considerations the implementation is impressive
  The technical architecture and implementation is impressive, especially if we take into account that it was originated in 2001 and based on In-House development. As far as the organizational maturity is concerned definition of Service management roles, Processes and culture is a significant milestone in the long road towards complete SOA implementation.
  

Definig SOA

Many years ago I read a Sufi tale about an elephant coming to a town in which all residents were born blind. No one of them have the slightest knowledge about elephants because no one ever traveled outside that town and this elephant was the first of his specie paying a visit to that town.
The blind people touched the huge elephant and disputed about the question: What this object is? A blind man/woman who touched the elephant's leg thought it is a pillar. Another one touching his ear thought it is a big fan. The third blind man thought it is a pipe because he touched its trunk etc. The blind people argued and argued and could not agree upon a common definition of that object.
The context of that tale is philosophical. However, when we look at SOA definitions we find partial definitions from the viewpoint of Developers, Architects, Analysts, System Administrators and Business people.
Business people may describe SOA as a collection of Business Services and Business Processes.
For Administrators, SOA is an infrastructure mainly Enterprise Service Bus (ESB).
Therefore some SOA initiatives are ESB projects with no additional implementations.
From Developers' perspective SOA could be seen as Web Services or Application Logic accessed from multiple End User Devices or an integration functionality connecting various applications or data sources.
The Architects could refer to SOA as an abstract Enterprise architectural style composed of multiple layers including Services, Interfaces, Processes, Data architecture and Metadata.
The System Analysts may refer to SOA as an application functionality relating to Business user requirements.
Do not assume that all Architects will agree upon a common definition. As example for Architects disagreements upon a definition see Arnon Rotem-Galoz 's blog.
If you think of agreement between non-architects playing the same role (e.g. Developers, Business People etc.), you will surely be disappointed: many Developers definitions will be found as well as many Administrators definitions are available.
Truly, the definition spectrum is narrowed when identical role holders define SOA, but still no consensus exists.
There are many disputes about what SOA is, corresponding to the argument of the blind people about the Elephant's definition.

The results are:
· Multiple definitions and sometimes contradicting definitions
· Partial definitions, which may describe some SOA attributes
· Different kinds of initiatives called SOA, but describing totally different real world implementations.
· Non-SOA implementations classified as SOA. A good example for Non-SOA implementations labeled SOA could be found in my previous post SCS and SOA.

Returning back to the Elephant and the blind people tale, probably no Value could be found for the blind people in any of the definitions: No blind man could use the elephant as fan or as a pillar and a combination of very cooperative elephant; very imaginative blind man/woman and available water source are necessary for using the elephant as an inefficient pipe.

The analogy is not complete: the partial SOA definitions could or could not have real Value for the definer or his organization. For example a developer may develop effectively a useful service using his partial definition. In one hand an architect may create good enterprise architecture or a good data model which may lead to real measured value. On the other hand the incomplete architecture may cause damage.

Even if the incomplete definitions are valuable still an enterprise needs at least someone who is not SOA-blind and can see the "Elephant" and understand the following aspects:

• What an elephant is? - What the Enterprise architectures and architecture elements are and what is the relationships between them (including both business and IT architectures)?
  
• What are the elephant's capabilities? - Organizational and technological maturity.
  
• Which discrete tasks could be performed by the elephant? - Services
  
• Which assignments composed of series of tasks could be performed by the elephant or the elephant together with a human being? - Automated Processes and partially automated Processes including human tasks (e.g. a process of approving and giving a loan which includes some non-automated approval tasks)
  
• What kind of elephant training is required so he can fulfill the tasks? - Which training is required for employees (including Business people, Managers, Technical IT staff etc.)?
  

Enterprises with no previous SOA experience are in a way like the blind people in the elephant tale. Usually the group or SOA Competence Center should include experienced consultant who knows what SOA is and could lead or mentor the internal participants at least in its early stages of the SOA initiative.

In summary:
1. Select a practical SOA definition (not a theoretical one which may not applicable for the enterprise)
2. Probably the definition should be adapted for each enterprise.
3. It should be a complete definition including elements related to real measurable value.
4. The perspective required for a complete definition is wide and probably requires cooperation between experienced consultant and internal experts with deep knowledge of the organizational business, organizational culture and technology.

SOA and SCS

The presenter in the 15th meeting of the SOA Forum of the Israeli Association of Information Processing (June 2007) was Brent Carlson, Founder and CTO of LogicLibrary who was named to InfoWorld’s ranking of the Top 25 CTOs in business today.
His presentation topic was: Service Lifecycle Governance: Principles and Best Practices.
Unfortunately, he was stuck in a traffic jam, so I talked to the forum members until his arrival.
I discussed the current status of SOA implementations in Israel. The two main points were:
1. Only few enterprises have a significant SOA production implementation
2. I am able to identify two enterprises that will surely fail in their SOA imitative just
by a short discussion with them.

One of the participants argued that my first point is not valid. He said that he is aware of enterprises implementing hundreds of Web Services.
I answered that implementing hundreds of Web Services is not necessarily implementing SOA.
Unsurprisingly, Brent Carlson's opinion was similar to mine when asked the question about these enterprises having hundreds of ungoverned Web Services. Brent named the ungoverned hundreds of Web Services: A Bunch of Services (ABOS) and not SOA.
I use the term So Called SOA (SCS) for describing initiatives which may be called SOA, may include Services (usually Web Services) Interfaces and Processes but do not form coherent Architecture.

The following attributes are common to these SCS implementations claimed to be SOA implementations:

1. No measurable Business Value measured by Return On Investment (ROI) or other criteria.
2. No Business and IT alignment
3. Low or no Reuse
4. No Agility or Flexibility for Business driven changes

Linking the last paragraph to my second point in the discussion about the initiatives I mentioned in the second bullet, I would say that I identified these two initiatives as SCS. However, there are a lot of definitions to SOA and SCS may be classified as SOA according to some of them.
When predicting that these enterprises will fell I did not predict that they will not complete SOA projects, I predicted that their implementations if realized, will be characterized by the four attributes of SCS cited above, especially the first attribute.
SOA initiatives costing more than returning in Long Term are failures.

The following characteristics of SOA initiatives may serve as "red lights" (warning) alerting creation of an SCS implementation:

1. Information technology (IT) only initiative.
No Business management involvement in the initiative.

2. Inadequate Organizational Maturity
Organizations which lack the required maturity level should postpone their SOA initiative and try to achieve adequate maturity level.
Do you expect an Enterprise which did not succeed in building any Enterprise Architecture to succeed in paradigm shift to abstract and layered SOA architecture? Of course not, a thousand miles walk begins in a single step.

3. Too ambitious effort
Big Bang style projects or three or four concurrent SOA pilots could be an indication for a doomed to failure initiative.

4. No usage of external expertise
"We do not need consultants" attitude of an organization which never implemented or planned SOA may result in creating non-SOA architecture e.i. SCS architecture.

5. Too Technical initiative
The term too Technical refers to the point of view that SOA is only collection of technologies. It is not. The result of the SOA initiative could be installation of SOA infrastructure products (ESBs, Registries, Application Servers etc.) without significant Services usage.
An example is an enterprise with multiple ESB's tools from various vendors, with no production SOA implementation. I let some of their leading experts know about another Infrastructure SOA tool installed in that enterprise.
How did I know about a SOA software product installed in that enterprise?
Well, I read a White Paper and asked the vendor for additional information. The vendor told me that although they do not have yet official distributor in my country they already installed the product in that enterprise.

Two questions related to this post will be discussed in next posts:
· Defining SOA
As there are many SOA definitions (some time incompatible and contradicting) the discrimination between SOA and SCS could be related to the SOA definition selected.

· What are the Worst Practices of SOA?
Worst Practices could lead to SCS failures as well as to other failures.

Web 2.0 For Dummies - part4: What is Web 2.0?

This post is the forth post in the "Web 2.0 for dummies" posts, based on my Web 2.0 presentation in a conference.

The following image depicts the Meme map build in O’reilly’s brainstorming.
This is the first and original Web 2.0 Meme map.
It should be noted that the model is a developing model with no explicit boundaries.








The central part includes the gravitational elements which are definitely the core of Web 2.0.
The Web as a platform mentioned in the previous post is one of that gravitational elements and not just one of the elements but a very important element.
The lower part in near to purple color includes principles, ideas and concepts.
The upper part (dark green) includes services examples and principles related specifically to some of them.
O’reilly’s model is not the only model. There are other Meme Maps.
Analyzing and comparing different Meme Maps is beyond the scope of this post. However, the multitude of models together with the flexible boundaries enables many vendors to label their services and products as Web 2.0, although in some cases they are very far from the Web 2.0 model.
Some of the main characteristics of Web 2.0 are cited in the following bullets:

• Uncontrolled (by vendors) Standards Based Platform
  The standards of the Web platform are not controlled by any infrastructure vendor or Web 2.0 vendor. As result of this characteristic Web 2.0 communities,companies and service providers use standards based solutions applicable to most of possible infrastructure solutions in the Web. Usually the technologies and architectures used for Web 2.0 services are relatively less complex.

• Social Computing

Many Web 2.0 projects and services context is social. Such as professional or social networks. Other Web 2.0 initiatives includes social interactions as well.

• Sharing Communities

Sharing could be the most important aspect of Web 2.0: Community members are contributing content, comments, voting, alerting about improper content etc. Notice that contributing is not limited to publishing content or code, but to other participation activities, such as rating.

Each Community has its interaction rules and patterns. The Community creates and improves "products". The cost model of building the "products" is a model which includes minimal or no costs for human resources. A community process is more democratic and more chaotic than a directed and controlled process within a company. This difference is reflected in the products: more innovative and creative but more volatile.
The notions of Community and Sharing imply trust in community members (sometimes without a known identity). It also includes build in Sharing ethics.

• The Hyperlinks are the Network

In a paraphrase of the old Sun slogan "The network is the Computer" we can say that "The hyperlinks are the network". Use of hyperlinks is one of the foundations of navigating between pages in the Web2.0 cyberspace or the global network.

• The user controls his data

From the vast amount of scattered data the user choose his data and controls it as part of his content or services. This it a two edges sword: In one hand the user has high degree of freedom, but on the other hand he has more responsibility and may use incorrect or outdated data.

other important concepts which will be introduced in future posts are Mashups and Longtail.

Potential for a lot of innovation, creativity, collaboration and cooperation is embedded in the culture of Web 2.0. However, there are many considerations: improper behavior, breach of trust and technical issues. The actual realization of breach of trust is varied according to the specific Web 2.0 project, service and community type.
The following problems are common to Web 2.0 projects:

Potential for a lot of innovation, creativity, collaboration and cooperation is embedded in the culture of Web 2.0. However, there are many considerations: improper behavior, breach of trust and technical issues. The actual realization of breach of trust is varied according to the specific Web 2.0 project, service and community type.
The following problems are common to Web 2.0 projects:

• Intentional improper content insertion
• Copyrights issues
• Unintentional wrong content or code insertion
• Intentional commercial bias
• Criminal acts
• Incomplete data or solutions
• Non Systematic and not fully robust implementations
  

The next posts will focus on specific Web 2.0 projects. The patterns for creating value in each of them are different but share common attributes.
There is also commonality between problems different Web 2.0 communities face. The specific manifestation of that problems and specific mitigation varies.
Please keep in mind the common attributes and considerations, while reading the next posts.

SOA & BPM

The topic of the meeting of the Israeli SOA Forum of November 29th was: BPM & SOA.
This is the 17th meeting of the SOA Forum of the Israeli Association of Information Processing.
I am moderating the forum since its imitation on March 2005. The forum meetings take place once in a month. The forum is opened for anyone involved or interested in SOA activities. Most of the meetings included presentations and discussions. The 16th meeting was exceptional: experts' panel on SOA Governance.

The presenter was Gilad Rothschild (ARIS product manager of Seker the local distributor of IDS Scheer's products).His perspective is Business Process Centric and mainly ARIS centric (and therefore focused on the modeling part of the Process Life Cycle). The view point of someone who is not a SOA expert, but rather an expert in business processes, as they are perceived by Business people instead of the usual IT people talking to IT people.

The following bullets highlight the key elements included in his presentation and/or the discussion:

• SOA and BPM which were two separated initiatives are converging
  The demonstration reveals an IDS Scheer SOA tool called ARIS SOA Architect, aiming at connecting the modeled Business Processes with the technical SOA implementation. The connection is by automatically generating BPEL diagrams, serving as a skeleton which is supplemented by additional BPEL code for execution under the leading Application Servers. According to a recent Aberdeen Group study 4% of the Best In Class (BIC) plan "to deploy BPM suites that don't provide SOA interfaces"
  
  
• Processes have Life Cycle from Modeling (including Business Process Analysis (BPA)) Implementation or Deployment, Monitoring (BAM), Improvement
  
  
• ARIS gateway between Modeling and Implementation is by pressing a button, which is the trigger for generating the BPEL. The gateway is bidirectional i.e. it is possible to generate the process model from BPEL code.
  
  
• The BPM tool Repository and its relationship with the Enterprise Service Repository and the Enterprise Service Registry
  
  

ARIS is a leading BPA tool according to Gartner's Magic Quadrant, but also by its selection as the preferred partner by the applications giants (SAP and Oracle and now also Microsoft).

Open issues discussed during the meeting:

1. Are there any BPM tools providing integrated solution for the whole Process Life Cycle? One of the participants argued that Lombardi and Agile Point tools cover the whole Life Cycle.


2. Dynamic Gateway between Process Modeling and Process Implementation vs. Manual or Half Automatic Gateway (as implemented by ARIS)
The notion of dynamic gateway refers to automatic update of the model due to changes in implemented process as well as update of the BPEL model in case of changes in the Business Model.
The discussion focused on two issues: is Fully Dynamic Gateway a realistic approach? And if it is realistic is it a better or worse than the Half Automatic approach?

3. The need to supplement the generated BPEL as a possible source for incompatibilities between the Business Process Model and The Business Process Implementation.

My take:

• SOA is not technology it is architecture of Business and IT alignment, so the view of BPM as a Business model and SOA as a Technical model is incorrect. Both SOA and BPM include Business view and Technical view. SOA Business view is the Business Architecture. Properly defined Services are defined as Business Services.
  
  
• The SOA Services may serve as building blocks of Processes. This approach may reduce the amount of supplemented code (Open issue 3) and narrow the gap between the Process Model and Process Implementation.
  
  
• The Bidirectional Gateway between model and code is analogous to the Bidirectional Gateway in CASE tools for Object Oriented: The generated code from UML design is just a skeleton, which should be supplemented by Object Oriented code same as the generated process code should be supplemented by additional code. The implication is that it should be easier to update a model from coed than to update code from a model. The implication may be valid for both Processes (BPA and BPM) and Program Functionality (CASE tools).