Understanding SOA

SOA is the buzz word these days. Gartner reports predict that more than 80% of applications will be based on SOA by year 2009. So, what is SOA and why is it picking up so fast?

SOA means different things to different people. Different parts of organizations have different motives behind adopting SOA. It has something for everyone!

We all know SOA is "Service Oriented Architecture", but what does it really mean? And more importantly what does it mean to an engineer? What does it mean to an IT organization? What does it mean to the top management? And what does it mean to a company as a whole?

Distributed Computing

Distributed computing is not new. Over the past 2 decades, we have seen it grown from simple 2-tier client-server architecture to 3-tier and then N-tier and p-2-p architectures. The goal of a distributed system has always been scalability, availability, and flexibility. Moreover, distributed architectures have helped companies to better align their resources (both human and hardware)

SOA evolution

Distributed computing allowed companies to break their systems into smaller components. This helped companies to realize the fact that a majority of these smaller components are not related to their core business and, in fact, are common across different companies and even industries. For example, entitlement and billing systems, payment systems, catalogue management, application infrastructure layers and even middle wares.

With the bust of dot-com era, companies started thinking about ways to lower costs. One of the most obvious was to out-source the non-core aspects of the business. The outsourcing and consulting companies find this really interesting, as they started leveraging their experience across companies and industries. The need for openness and ability to consume third party services led to the advent of web-services and Service Oriented Architecture (SOA).

Software as a Service (SaaS) and SOA

Software delivery as a service has grown rapidly as more and more companies have realized that they can keep the customer relationship active by delivering software as a service, rather than delivering one-time products. I see SOA as a SaaS enabler.

What does SOA mean to an Architect?

SOA provides loosely coupled components. Each component is implemented using open standards for flexibility and future expandability. Architects need to make sure that there is no Single Point of Failure (SPOF) in the end-to-end system and, in some cases, are forced to implement extra caching mechanisms to improve availability and reliability. SOA brings simplicity back to architectures.

What does SOA mean to Development?

To developers, SOA means smaller teams and shorter development cycles. However, SOA also means more coordination across different teams and requires developers to follow standards.

What does SOA mean to an IT organization?

SOA enables faster release trains. With SOA, not all components needs to be upgraded at once. That means Bug fixes can be delivered faster, safer and easier. Less downtime and happy customer. SOA provides business agility. SOA enables continuous change!

What does SOA mean to Management?

SOA means large number of smaller projects rather than one monolithic project. Till date, it has been a nightmare for management, as they have not been able to grasp the power of SOA and the concept of smaller projects. To management, it only means more projects. Since Software development has been famous for not following discipline and processes, SOA has caused more harm than good. SOA requires engineering discipline and standardization.

A lot of organizations have been caught in the messy middle - the market environmental pressures are forcing them to enable SaaS and adopt faster release trains, Technology office and architects are pushing SOA, and the managers are stuck with their dogmatic viewpoints around waterfall methodologies. Engineers are confused, not knowing what to do, and quality is the last thing on anyone's mind.

The irony is that SOA goes hand-in-hand with agile development methodologies like Scrum. If and only if the management can be trained in SOA and newer development mythologies like Scrum, the companies can dream of coming out of this messy middle.

Changing market environment and industry pressures have forced companies to adopt SOA, but not everyone in management is even aware of the change. Management needs to be trained with new ALM tools to be successful.

What does SOA mean to a Company?

SOA enabled applications live longer and the ROI curve becomes very lucrative very fast. For companies, SOA is a blessing (if only they can deliver it right).

Final Thought:
SOA requires better ALM tools and integration of processes. The dependency among different components of SOA is not trivial. Sophisticated tools are required to orchestrate the whole application life-cycle management.

Trackback URL: Understanding SOA

Automation: Beyond Testing

Automation is the key to productivity in any functional group in any organization. But for majority of people:

• "Automation" = "Test Automation"
  

The general perception is that we should spend all our resources in automating test cases to cut-down test-cycle times! Well, that's not entirely true. Test cases are a small piece of the overall puzzle. Automating test cases is important, but it alone does not gaurantee reduced cycle time and faster release trains.

We must automate not only the overall testing process (which is far more than just automating test cases), but also other processes that takes up considerable amount of resources and are prone to errors. The biggest problem with automating processes is getting buy-in from the top management and all the cross-functional teams they impact. Moreover, some people see automation as a threat to their job and hence never fully support the idea. However, the fact remains that to boost productivity, one must maximize the use of labor and capital - which can be best achieved via Automation!!

Automation has following benefits:

• An automated process tends to live longer and ROI follow an exponencial curve.
• Automated processes are a lot easy to follow.
• Automation provide repeatability and consistency and boosts the quality of the process itself.
  
• Good quality processes results in good quality products (TQM principle)
• Employees get more frustrated by the process relaeted issus. A lot of product related issues are there because of broken processes.
  
• Process Automation makes the upper managaemet's life easy. It generates data and trends which can significantly impact decision making.
  
• Automated process reduces the ramp-up time for new comers, as processes are a lot easier to understand, once automated.
  
• Process Automation is an investment in the infrastructure.
  

So, how imporant is it for a team to invest in automation beyond testing? The answer is "It Depends." It depends on the complexity of the team, its structure, size and the amount of decentralization. Processes becomes overhead when your teams are small and localized, like in a startup. Most startups hate processes. Whereas the processes become really important when team grows in size, members work from home and are distributed globally in different timezones. Processes also makes sense when team members are of mixed experience as a result of attrition and growth, and there is a growing need for cross-functional collaboration.

In case you are wondering which process to automate, here is a small list of ALM sub-processes, which are a good pick for automation:

• Requirements Management
• Version Control, Build and Release Management
  
• Change Management, Request to Integrate (RTI) Process
• Patch Management
• Request for Change (RFC) Process
• QA Acceptance, Sanity testing
• Overall Testing Process (includes test management and test automation)
• Continuous Integration
  
• Deployment
• Defect Management
  
• Customer Escalation Management, Issue Tracking
• Program Management
• Monitoring (servers, errors, thresholds, CPU, memory, I/O, response times, availability)
  
• End-to-end real-time reporting
• Dependency Management (must for SOA applications)
  

Process automation doesn't mean going out of limits and defining a process and then automating it. Start by identidying iterative activites that happen very frequently and are annoying. For large and distributed teams, where it's hard to get a handle on productivity, processes are a breeze. And if there are processes, they need to be automated to bring standardization, acceptance, speed, and higher overall productivity.

Final Thought:
If there is a process, it better be automated!