Service Oriented Architecture (SOA) - God's Own Architecture

Intended Audience: Anyone and Everyone!

Service Oriented Architecture (SOA), has for long been used by different people in different ways. Some have used this three letter buzzword to sell their products (without actually understanding what it really meant!), while some (a handful) have passionately sold their products by truly implementing SOA. Though there has been a lot of information about SOA in the internet, its always been a tough task to explain this to a layperson (say, a doctor or a fashion designer!)

In this article, we'll try to step aside from the 'serious' and 'geekish' SOA discussion, and get into a lighter way of looking at this three letter buzzword. We all know how complex God's creations have been. From the universe (this is still a black box to mankind!) to the creation of humans, God's creation has always amused mankind. In the IT parlance, God is the supreme architect of all what we see around and inside of us. For the sake of dicussion, in this article, lets consider the Human Body (yes, our very own body!) as a product, and SOA as the architecture. Do you see some similarities? Read on...

Before we jump any further, lets quickly recall the SOA Reference Architecture, as defined by IBM (an undisputed leader in this space!)

Above picture shows the SOA Reference Architecture defined by IBM. A closer look at it shows the different aspects of the SOA. The Enterprise Service Bus is the core integration backbone of the SOA. The rest of them are self-explanatory. Without delving much into this, lets quickly jump back into our mainstream discussion - God's Own Architecture.

Lets extend SOA to the Human Body. As we all understand, the human body is one of the most complex, robust, flexible and agile systems. The below diagram is what I used to explain SOA to a doctor friend of mine.

A closer look at the above diagram will be good enough for you to understand the similarity. The Spinal System is the core of the human body (Its the integration layer!). The human brain takes care of the Process and Interaction Services. The human body is the most complex implementation based on SOA! This is very obvious with the fact that one cannot map a certain part of the body to only one aspect of SOA. For example, the human brain is so complex that one cannot rule out the participation of the human brain in Partner Services or Interaction Services.

In simple terms, apart from making laypeople understand SOA, the attempt here is to convey that Service Oriented Archtiecture (SOA) is God's Own Architecture (or, atleast close to it!). SOA has to be applied to the context of an industry to be able to understand its actual business value. In this article, we took the human body as an example. One might also want to consider the Solar System (with the Sun as the ESB, and so on) when explaining SOA to an astronomer.

So, Remember...SOA as a plain technology or business statement DOES NOT sell (and the world has seen this)! Industry content is the key!

CIOs and IT Leaders - Having SAP Nightmares? Read on...

I've seen a lot of buzz around SAP and heard a good number of my customers/partners raise this concern in the past many months. I've also been following the series of articles by Thomas Wailgum at CIO.com on this topic. In this article, we'll try to take a few steps back in time, and understand how it started. We'll also see how it evolved over time. Towards the end, we'll also see, as leaders in the IT space, a way to tackle this. The its and this' refer to the ERP bugaboo.

It all started in the early 2000's, right after the dot com boom, when the senior IT management teams of many companies wanted to manage their wide spread businesses effectively. From a management perspective, they thought that having a single ubiquitous platform would help from both talent acquisition and software management perspectives. This was the time when SAP's ERP suite was launched (mySAP ERP was launched in 2003). This suite offered four individual solutions, each addressing specific functional areas, namely-

1. Human Capital Management
2. Financials
3. Operations
4. Corporate Services

Over the next few years, these customers of SAP were happy with their investment decisions. These companies started to implement these solutions for their enterprises. But slowly, over a period in time, these companies pretty much reached a stage where they completed implementations of these solutions. As their corporate footprint and needs increased, they sought SAP's assistance to deploy these solutions for the newly inducted companies as well.

In the background, there was this monster called complexity that was growing. SAP was continuously adding newer features and releasing newer versions of these solutions. With the new deployments of SAP's solutions, these customers slowly started to realize that they needed to manage these different versions of solutions across their enterprises. This is when SAP introduced their Netweaver integrated technology platform, which was intended to help manage this complexity of different SAP versions. However, they later chose to call this a service-oriented application and integration platform.

Assuming the above fixed the problem of complexity, these companies started to look at the other side of the business - beating the competition and creating a unique business value to their customers. This resulted in the business teams of these companies coming up with some strategic initiatives and strategic business processes. This is when the ball was thrown back to the IT Leaders and CIOs to think of ways to implement these strategic business processes.

Still enchanted by SAP's ERP solutions, these IT Leaders resorted to implementing these strategic business processes in the same SAP platform using the programming languages like ABAP, etc. Now, the monster started to surface again! This time, it came with a greater force and impact. With the existing complexity of managing different versions of the SAP ERP, the companies were now put through a challenge of having to deal with different versions and fixes of these individual custom processes/modules that were deployed to address their strategic initiatives.

Let us now try and remind ourselves that SAP ERP was designed to address the resource management related processes (related to corporate operations, financial processes, human capital managment and the like). These processes are typically found in every enterprise, whatever industry or business they may be. When we talk about strategic business processes, we refer to those unique business processes that help an enterprise/corporate differentiate itself from its competition. The truth is that SAP's ERP was NOT designed to handle this! So, it was a Square Peg in a Round Hole.

IT Leaders looked at managing complexity in the short term, but failed to see the complexity in the longer run. So, is there a way to tame this man-made monster called complexity? Yes, there is. Read on...

Start differentiating between your strategic business processes and your ERP processes. Keep the latter in your existing ERP and move the former to a common, enterprise-wide platform that conforms to IT and Industry Standards. It's very important to think about the IT and Industry standards because your enterprise is bound to have disparate lines of businesses and different softwares from different vendors. You will need to have a platform that will seamlessly integrate these different systems and software.

From an IT Standards perspective, Service Oriented Architecture (SOA) has is a proven approach that offers the maximum flexibility and seamless integration capabilities. Though SAP-AG chose to call their Netweaver platform as a service-oriented application and integration platform, it isn't really so. Just because your integration platform allows its applications to be exposed as Web-Services, does not mean that it is SOA compliant! To know more on the difference between SOA and Web-Services, read this article.

To summarize, take a closer look at your ERP usage and try to separate out those non-ERP business processes. Adopt the SOA approach to your enterprise's IT architecture. It helps your business and IT be more flexible, agile and robust.

For further reading:

1. AMR Research article titled SOA will kill ERP
2. Forrester Research on ERP and SOA
   

Busting the myth about SOA and Web Services

As I've mentioned in many of my earlier posts, people have increasingly confused the terms SOA and Web Services. Though companies and people are getting aware of the Service Oriented Architecture paradigm, some misconceptions still exist. I was recently on a telephonic conversation with an executive of a company, to explore options of working jointly in some areas of business and IT. I was totally surprised when I heard him say -

Our solutions are all based on Web Services. They are all SOA-ready

I asked him if he was aware of the differences between a solution that is based on Web Services and a solution that is built based on the SOA reference architecture. I was surprised to hear his reply -

Yes, our solutions are based on Web Services, which is why I said that they are SOA-ready

Getting back to the present moment, let me take a minute to define what Service Oriented Architecture really means in simple terms -

SOA is a flexible architecture of business capabilities being supported by loosly coupled IT elements

Web Services simply means "a software system designed to support interoperable Machine to Machine interaction over a network"

To summarize, Web Services are the building blocks of SOA; Web Services is not SOA!

For a better understanding on the fundamentals, please visit this link.

SWYL : What is the difference between Architecture and Design?

One of the most widely used words in the IT world are design and architecture. But many a time, these two words have been used wrongly. In some places we see the word architecture being used for a design and vice versa. Each one of us might have had this problem ourselves during early the stages of our IT career.

One of the definitions I found on the internet said -

"Design is the description of how something works within a given set of constraints; architcture is the description of a system of constraints

Another webpage read -

"While architecture deals more with the wide picture, design should drill down in to the details relating to implementing certain components

Here is what I think are the differences between architecture and design -

1. Architecture is purely driven by the business requirements, while design is driven by component or module level requirements
2. A change in the architecture can affect the end solution, while a change in design will not always affect the end solution
3. An architecture can act as a framework (generic) for a set of solutions. But a design cannot be generalized for a set of solutions
4. Architecture is bound by the business environment, while the design is bound by the architecture
5. The architecture is defined by requirements collected from Line of Businesses (LOBs) and the environment where the end solution needs to be deployed. Design requirements are defined by the boundaries of a component or module
6. Requirements that go into the making of an architecture is not direct (as it comes from non-IT/business community). The Architect will need to infer a lot of the needs. Design requirements are predominantly direct and defined by the component constraints and the architecture

These 6 differences are just the key ones. There are many others that differentiate design and architecture apart from the above.

SWYL : What is Architecture?

Definition of "architecture" used in ANSI/IEEE Std 1471-2000 -

"The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

My definition of "architecture" -

"Essential characteristic features, attributes and properties of an object and its surroundings/ environment to address a particular goal or desired To-Be state.

The above definition of mine comes from my understanding of architecture and from the degree of discomfort I have in terms of the differences between architecture and design.

The IEEE definition of architecture talks about components, their relationships in a given environment, and design principles. There are a lot more than just components, their relationships and principles.

Civil Architecture presents a simple analogy to the word "architecture". We can understand that the civil architecture is not all about foundation, beams, columns, roofs and walls. Its also about types of foundation, soil, cement mix ratio in the case of a concrete, diameter of iron rods used for cement concrete, thickness of beams, and so on.

Six Key Roles & Responsibilities of a Solutions Architect

A Solutions Architect will essentially need to take some key responsibilities during the course of a project. Here are 6 key responsibilities/ roles that I think are the most important ones -

• Solution delivery - The Solutions Architect (SA) is responsible for the delivery of a particular solution on the date committed. At times, this is shared by a Project Manager, but most often, the Solutions Architect is responsible
• Project Timelines/ Schedule - Its an SA's duty to make sure the project is progressing in the right pace. The SA typically will work with the Project Manager to accomplish this task
• Solution Architecture - The SA takes complete responsibility of the Solution Archtiecture. Though, in the process, the Solutions Architect might consult the Integration/ Infrastructure architects, the end product is owned by the SA
• A Consultant - The SA also dons the role of a consultant during the early phases of the solution, when the SA needs to gather requirements and work with the sales team to put together a document in return to a Request For Proposal (RFP) from the customer
• Subject Matter Expert - The Solution Architect is also a key person who understands the solution and the domain/ industry well. The Solution Architect needs to be a Subject Matter Expert (SME) to be able to understand the customer's requirement and also suggest alternatives to better the solution and alleviate the challenge/ issue being addressed
• A Leader - A Solution Architect needs to be a leader who can efficiently lead a team of developers, project manager and effectively work with other business units in the company and the customer team in the creation of the solution. The SA should be able to work with the customer and help them envision the solution value, and how it will benefit them in the longer term

These are just six of the key responsibilities that come to my mind. Should you have more thoughts here, do mention them in the comments and your name!...I shall update the post with your comments.

Solution Architecture - How is this different from Enterprise and IT Architecture?

There was a gentleman who recently asked me a question in the context of my current job profile. He asked me

"What is your role as a Solution Architect, and how is the Solution Architect's role any different from an IT Architect or an Enterprise Architect?"

I did explain him the differences and the nuances of each type of architecture. But I also promised to post an article on the same. Hence this.

I forgot to cover this as one of the "most (ab)used words" in my previous article. The words "Enterprise Architect", "IT Architect", etc have been highly misused by people. No offense meant - Companies have used this as a "designation" rather than a "role" in some cases. I hence thought of clarifying these so-called ambiguous terms by outlining the differences between each type of architecture in the context of an Enterprise Architecture. (in conformance with The Open Group standards and definitions)



EA - Enterprise Architecture
EBA - Enterprise Business Architecture
EITA - Enterprise IT (EIT) Architecture
EITIA - EIT Information Architecture
EITAA - EIT Application Architecture
EITTA - EIT Technology Architecture
EITSIA - EIT Software Infrastructure Architecture
EITHIA - EIT Hardware Infrastructure Architecture
SA - Solution Architecture

I hope this has been useful.