SOA in MOE and LOE

More acronyms - MOE and LOE. May be due to my roots in Telcom domain, I am used to acronym in day to day life. MOE means Management Oriented Enterprise and LOE means Leadership Oriented Enterprise.

MOE is basically a type of culture prevalent in Enterprise. In this type of Enterprise, there exists lot of committees. Every decision is approved by hierarchy of people. Decisions are based on big reports. Long discussions take place to improve the efficiencies. Every big enterprise has processes. In this enterprise, employees follows all the processes to complete milestones. It helps to check the progress but the value of each step in process is not evaluated. Employees just complete the activity to tick the completeness. Delivery is primary focus.

LOE is another type of culture prevalent in Enterprise. In this type of there exists Leaders. Leaders at all levels. These Enterprises also creates lot of small committees. These committees come up with small action items. They believe in pilots, POC, prototypes instead of big reports. Long discussions too happens but with actionable outputs. Processes are followed and employees try to add value in each step. Quality is primary focus.

Somehow, I feel MOE adopts top down approach of SOA and LOE adopts bottom up approach due its culture. A push for top down in LOE is going to be much more successful than in MOE.

Candidate for the EDA

For a long time, I am reading excellent posts on SOA and EDA blog by Jack Van Hoof. EDA reminds me of Telecom domain. This domain is excellent candidate for EDA. Telecom network generates the events. These events are intercepted by application services like Prepaid, Ringback tone, Follow me, VPN etc.

Explaining my point with scenario like execution of Single Service -
Consider scenario where prepaid caller dials a called party number. A event is generated, service capture the calling party number and called party number. Based on called party number it routes the call. Now caller listens the ringing. Called party picks up the phone. Another event is generated. Service captures the events and starts charging. There is voice channel between caller and called party. After sometime, called party hangs the phone call. Another event is generated and service based on this event stops charging and persist the duration of call. In this flow, based on current event and last event result, application service executes the business logic. There is requirement for storing the state of call. This makes scenario little bit complex. Events cann't be consider stateless in real sense.

Execution of Multiple Services
In this case, one approach is to introduce Service Manager and this Service Manager further manages the interactions with several services and their sequencing.

In contrast with Enterprise application, Telecom applications are more chatty i.e. Events are too many and are of very short duration. Due to this, scalability and performance becomes burning issues. Secondly, all these events are in real time. While events are processed, customers are waiting for call to connect, waiting for ring back tone, announcements etc. It makes true testing ground for EDA.

In last, I feel, SOA and EDA could change the landscape of Telecom services. Niche companies could provide services like charging, rating, application services on internet. These services could be consumed by operators instead every one building themselves. Telecom domain is always a front runner at concept level. Hub & Spoke model of Telecom switches was innovated three decades back. This model is foundation for buzzword ESB nowadays.

SOAtization of Enterprise Culture

For last few years, whenever any projects is initiated or any product is launched, it claims to be following principles of SOA. Most of big Enterprise claims that they are in process of successfully adopting SOA. To measure the maturity, one can find many SOA maturity models on lines of CMMi models.

Actually, SOAtization of Enterprise is a change in culture of Enterprise. One needs lots of impact players, support of management, proper communication to developer community, strong collaboration with business and Enterprise Architecture team.

SOA is a concept, architecture approach and above all its a cultural change. Enterprise starts discussing in taxonomy of business processes. Top down approach is followed to find business services. Delivery teams believes in building reusable business services and infrastructure services. A proper governance exists and services are registered in repository. People don't owns the applications and projects.

Simple way to check the SOAtization of the Enterprise is to find whether people are building business processes or applications.

SOA - The Elephant

There is always a debate who should drive the SOA initiative in Enterprise. It could be business, architecture team, delivery or Operations team. It benefits all of them in different ways. SOA from different viewpoints looks like
- Business see SOA as a set of business services that are exposed to its clients. It reduces the time to market and costs of building business processes. It increases business agility and simplify the IT.
- Architects see SOA as an architectural approach to build business processes. It is based on well known principles and patterns like loose coupling, separation of concerns, encapsulation etc. It constitutes of provider, consumer and contract.
-Developer see SOA as a set of standards, tools and technologies like Web Services.
-Operational people see SOA as a better contract between Service provider and Service consumer.

In my view, SOA impacts the entire Enterprise and everyone is stakeholder. Unlike earlier concepts of distributed computing in IT, SOA is more near to business people. Hope IT will fulfill the agility and reusability promise this time.

Shelf life of Software Project

A IT team develops a project and it is deployed. How long the application is going to be in production? Most the time average life of software project is around 3 years.

After 3 years, project might require a major upgrade and re-engineering in terms of technology and business.

Most of time systems wants to upgrade the system. There can be multiple reasons like
- infrastructure has reached end of life.
- it is not possible to extend the functionality. Application has become so brittle and requires lot of maintenance.
- it is not possible to satisfy the performance and scalability needs of business in near future.

Sometimes business wants to change the business process drastically. It is difficult to change the existing application. The only option left is to build a new application.

Now a new huge investment is required to create a new application silo. Oops !! Not again.

We all understand now that moment is right to increase the shelf life of software project. It could be possible by adopting SOA. Loose coupling between services provides to opportunity to increase the shelf life of software project.

An interesting thought, think about the layered architecture. Top layers have much lesser shelf life in comparison to layers below. Presentation tiers expires much before the Data tier.

SOA Repository

Todd Biske blog on Master Metadata/Policy Management escalates the very valid point in space of SOA.

Repository/Registry is one of the building blocks on SOA roadmap for any Enterprise. Foundation of SOA is based on Loosely Coupled principle. Vendor specific central repository violates the SOA driving principle.

Enterprises should create standards & guidelines for the central repository and moreover, for the services which could be added in repository itself.

Please see blog entry Empty Registry Syndrome for more details.

Story about a sweet couple (OOAD and Business Analyst)

Once upon time, technologist OOAD met visionary BA. We all know opposite attracts, they were surprised to see the differences among each other. OOAD used to do work without thinking and BA only thinks and no work.

But they were destined to work together for many years. As time passes by, they fell in love with each other. Now both of them are trying to live together and are blessed with two prodigy sons. Currently, these kids are undergoing training in big enterprises.

Let me tell you little bit about them before introducing -
1. Put both of them on any project and forget about project. Only God knows when they will deliver it.

2. It is hard to measure how much work they have completed.

3. They take guidance from their parents but their way of working is totally different.

4. Both of them are very naughty and it is quite hard to understand what they are delivering.

5. They are too young and new to world. It is hard to have confidence in them. Sometime it gives impression that they will fail.

Some wisdom - give them space and time, let them grow with time and they are destined to change the world. Trust them. Two sons are SOA and Enterprise Architecture.

Attended SOA conference

SOA conference was organized by iCMG and Clive Finkelstein, MD, IES presented his views on Enterprise SOA. It encompasses sessions on EAI concepts, SOA & Web Services, Rapid Delivery using SOA and BPM, New Directions for ERP & Legacy.

I am quite impressed by Sunil Dutt Jha, CEO of iCMG.

Avoid burning your hands

Please avoid reading this entry if you think you are creative enough to find a new way to burn hand.

It is desirable nowadays that Architect not only know the Patterns but also Anti-Patterns. Similarly, understand the benefits of SOA and adopt it. But also be sure to research on pitfalls and risk associated with SOA.

Few points to avoid burning hands with SOA flame -
1. No Big Bang - Avoid this theory in Software industry, this is root of hundreds of failures.
2. SOA is concept - Never in software industry, there was a concept which has such an impact. Try to find the right technique to realize the concept in real world. Web Service is not only one.
3. Sell SOA - Everyone in enterprise is stakeholder of SOA. Sell to everyone for success.
4. Never ending SOA - Find out where your Enterprise stand in SOA maturity model.
5. Think end to end - Every project has functional and non functional requirement. Don't miss SOA non functional requirements - Performance and Security.

First impression of SOA on Business user

Is Business user ready to accept delay in response? Is it matter to Business user whether the services consumed runs on old legacy architecture or hyped SOA architecture? What all matters to Business user is usability? Any upgradation in technology should improve the functionality and quality attributes. First step towards SOA impacts performance. Decoupling of components/services with help of XML creates overhead in terms of XML processing, transformation and routing of messages. All these steps eats up significant processing time of request.

First step towards SOA doesn't create positive impression on business user. It becomes difficult to sell SOA to business stakeholders. Short term hurdles stops adoption of long term benefits of SOA.

SOA looks quite similar to Remote Entity bean concept in EJB 1.0. Conceptually, both are suitable for ideal scenarios. They attract purist who wants to follow the architect principles without business value. One may say Entity beans were fine grained domain objects and SOA are business services. Session beans orchestrate entity beans, similarly BPM orchestrate business services. Does any thing like local interfaces concept will emerge in SOA world?

SOA makes sense in case of B2B and services which are exposed to external clients. But within scope of Enterprise, do we want to consume slow business services. Its a call between performance vs flexibility. Lets see who wins or we are able to find the win win situation in time.

Nuke in the arsenal of Enterprise Architect : SOA

Architecture skill demands continuous improvement. Its a journey not an end. Architect should be able to enhance his skillset as and when job demands.

It is predicted that SOA will reduce the overall IT expenses in enterprise. It means time is right to build SOA skill and campaign for SOA adoption in enterprise .

I love analogies to explain my point, compare SOA with a nuke in arsenal of EA. Not every country in world has Nuke, still they survive and most of them have ambition to develop one in future. Furthermore, same nuclear technology can boost the country economy or can destroy it. Depends how it is handled. Advise is to handle SOA with care.