Posts tagged ‘governance’

SaaS Governance

The other day, I was talking to a company that posed an interesting question to me – they are a typical ISV developing on-premise software products, however, they have a need to develop and expose certain (hosted) services that need to by consumed by their end customer, which these customers can customize to a certain extent. So the question was – who is responsible for supporting these services if something does not work and how do we know what the underlying cause of failure was so that we can determine who is at fault and who should be fixing the problem?

It’s a very good question, because this ISV is entering a hybrid model – where their on-premise business model is now complemented by their hosted services model (not really SaaS because it might not be a multi-tenant single instance architecture). Before, they could create their product, package it, sell it and then let the customer worry about the operational aspect of it – if there was infrastructure downtime, it was the customer’s headache. But now, if the customers consume these hosted services which they can also customize and something goes wrong with the service, who now supports the problem? Was the problem due to the customizations that the customer did? If so, is it the customer’s problem? If not, then it should be the ISV’s problem. And how does one determine what caused the problem in the first place?

This is an issue many ISVs who are moving to SaaS struggle with. Every SaaS customer should have the ability to customize – customize the UI, customize workflows, customize the data model to extend it to suit their needs. Yet, every SaaS provider is faced with the challenge of providing uptime while at the same time allowing their customers to tweak the service. So how does the provider and consumer figure out who is using which service, when, under what conditions and what should be done in the event that something goes wrong?

That is where SaaS (and in general, SOA) governance comes into play. Governance is one of those overused words that is thrown around casually and it can mean different things to different people. Governance to a developer means something different than to an auditor. Governance, especially SOA/SaaS governance is about conformance and compliance. Are my developers writing code that complies with my Enterprise Architecture standards? Are my developers conforming to the standards and frameworks that should be used for developing certain products or projects within the enterprise? How are my product/project artifacts being advertised to other development teams? Who is reusing my artifacts during development, on which projects and how much time is it saving them? Who is consuming my service at runtime? Is the service doing what it advertises it does? All of these questions, and many more, fall under the realm of governance. Keep in mind that what I am talking about here is mostly SOA/SaaS governance, not IT Governance, which encompasses many other things like architecture, data and infrastructure governance, corporate governance (SOX, etc), disaster recovery and business continuity, etc.

So coming back to SaaS governance, how can it help this ISV to solve their problem? The answer is Service Level Agreements (SLAs). Most product companies do not have a lot of experience when it comes to crafting SLAs, simply because it has never been a concern for on-premise product companies. As I mentioned before, they are used to creating software, packaging it and selling it under a license and once the product is sold, it’s deployment and operations are now really the concern of the customer that just bought the product. However, SaaS brings with it it’s own set of challenges for companies, in particular ISVs who are now held responsible for the operations of the service that they are selling. So what exactly is an SLA and how does it help protect both the service provider and consumer?

In simple terms, an SLA is a a contract that exists between the SaaS provider and their customer that describes the level of service that the provider will provide and the customer should expect from that service. It details the availability, performance, operations and other areas of relevance to the service being provided and in many cases will even provide details around the penalty should these terms not be met. For the provider, it is a way to set realistic expectations for their customers. The for consumer, it is a way to hold the provider accountable should the provider violate the SLA agreement. The point of importance here is that the SLA should not be loathed by the provider or be seen as a way to hold the provider hostage by the consumer. It should be viewed as a way to open up the communication channels so that both parties can come to terms on what is acceptable and should be used as an objective way to measure usability, quality and accountability by both parties. But make no mistake, there is some level of negotiation that definitely happens as part of crafting an SLA. An SLA goes into great detail outlining the availability, reliability, performance, the types of support available along with the associated timings, penalties should these metrics not be met (usually in the form of credits), classification of problems and associated response times, etc.

In summary, it is important to remember that an SLA is not a guarantee of service uptime. It is merely an insurance policy. However, it is an absolute must for both service provider and consumer to have an SLA in place so that both parties are protected in the event of an event. In my mind, an SLA is not just there to benefit consumers. Just as providers have a responsibility to their customers to provide their service in a highly reliable, available and scalable environment, consumers too have a responsibility to use the service responsibly, to not interject anomalies into the system by trying to do something that is not supported by the provider which should be clearly states in the SLA, etc. The SLA helps to open up communication between both provider and consumer and helps manage customer relations.


March 4, 2008 at 4:43 am Leave a comment

The 4 Pillars of SOA

I thought that I’d start my first technical post on a buzzword that has already been overused (and abused) quite a bit – SOA. Many books have been written about SOA and this post is not about going deep into SOA, but more so, an introduction into what SOA is at a very high level. Over the next few posts, I will get deeper into SOA, what it entails, what the best practices are, how companies can build out a road map to get started on their SOA journey, why governance is important and much more.

SOA stands for Service Oriented Architecture. Over the years, there has been a transition from mainframes to client server to the web. As a result, many companies have a hodge podge of applications, technologies and infrastructure in their IT environment. Disparate languages (COBOL, Java, Perl, .NET, etc), different platforms (Microsoft, Linux, IBM, etc) and different databases and data sources (EDI, flat files, XML, relational, object oriented, etc) means that often one application cannot talk to and access data from other applications within a company. Customer data might be spread out over 2 or 3 data sources. Business processes exist only on paper and hence there is no automation. Multiple applications need to be accessed to gain insight into customer information. Business logic is strewn all across the place, making it hard to keep track of and maintain duplicate logic. The business folks keep churning out new requirements while the technical folks can’t keep up with the requests and instead keep building non-reusable, highly monolithic applications that take up time, energy and money and produce little in terms of future benefits to the business. The list goes on…

SOA is an architectural approach that tackles these problems head on, aimed at breaking down these siloed applications and data sources and creating the potential to share processes, logic and data amongst applications within and outside the corporate walls. At it’s very core, it is concerned with building services out of existing and new applications such that they can be composed together to quickly build newer applications. This should result in a more adaptive business, shorter development cycles, more maintainable code, faster time to market, centralized business logic that is easier to debug and test, etc.

When people think of SOA, they think of web services – how to build them, how to test them, deploy them and monitor them. But that is only but a part of the bigger SOA picture. When companies think of embarking on SOA, they need to approach it from a much broader perspective, otherwise their SOA initiatives will fail (and a lot of them have). So what the are the areas that make up an SOA implementation? In my opinion, any SOA architect needs to tackle SOA from 4 angles. I call them my 4 pillars of SOA:

1) Architecture
This aspect deals with the “A” in SOA. What do we have in place? What can we harvest? Where are we today and where to do we need to be? How does the architecture reflect the business needs (this is very important because at the end of the day, you are not doing SOA because it’s cool – you are doing it to make your business more agile), what are the gaps in the current and future state and how do we bridge that gap? What standards and protocols should be leveraged to build open, extensible systems? What are the entry points into SOA and where/how do you start? These are the issues that need to be addressed as part of an overall SOA strategy.

2) Infrastructure
So you want to build services to get your applications talking. But in order for your architecture to be robust and scalable, you need the right infrastructure in place. By infrastructure, I mean things like an Enterprise Service Bus (ESB) to mediate message formats and protocols, a portal to tie in disparate web applications, a repository to house your reusable assets, a registry to enable users to discover your assets at runtime, security infrastructure, monitoring infrastructure to manage service level agreements (SLAs), virtualization infrastructure, etc. Without infrastructure, you’ll soon go from a hodge podge of siloed applications to a hodge podge of services developed by different teams without appropriate documentation on who has developed what, what’s available for reuse, which projects are consuming what, how much ROI are you getting from SOA, and a whole slew of other problems. This is not to imply that everything needs to be in place right away, but it is important to note the need for infrastructure and to have an incremental roadmap in place to ramp up on infrastructure gradually.

3) Service Engineering
Many consulting companies say that they do SOA. They might have accidentally done SOA for their customers in the past by building out a few web services for them and touting that as their foray into SOA. However, that is far from being experienced in SOA. As I mentioned earlier, SOA is not just web services. But being able to servicize assets is core to SOA and building out services willy nilly is a recipe for disaster. Service Engineering is a well planned and thought out framework that lays out in great detail how to go about analyzing assets to harvest services, how to identify ideal candidates that can be servicized (service portfolio planning), release planning, how to build these services, how to test them, how to deploy them, monitor and manage them. Think of service engineering as start to finish best practices for planning out your service portfolio.

4) Governance
Another overused word in the world of SOA. Hopefully, you can see from this post that SOA is more than just about web services. I have worked on many complex SOA projects with customers and from those experiences, I can tell you that it takes more than just service implementation for a SOA project to succeed. From the onset, a customer needs to be made aware of the costs of doing a SOA project. Proper teams need to be in place to manage SOA architecture and infrastructure decisions. Policies need to be created and enacted, both at the enterprise, project and service level to track progress and monitor metrics. All this is dealt with using proper governance frameworks. Governance means different things to different people – to a developer it means conforming to project requirements and guidelines set forth by the architect and reusing components that already exist. To an architect it means ensuring that developers are complying to development standards, leveraging reusable assets, tying services to policies, etc. To a business person, it means something different – they are more concerned with SLAs and making sure that IT is delivering what it promised. So IT governance frameworks such as ITIL, and more specifically, SOA governance frameworks need to be put in place to make SOA a success. But make no mistake, governance takes a lot of work and that is why a lot of companies shy away from it. The trick is to not jump neck deep into governance, but as with SOA, do it piece meal – do what is relevant today and leave room to grow into tomorrow’s requirements…but start SOA with governance, instead of making it an afterthought.

This hopefully gives you some insight into SOA and what it entails. The message here is not that you need all this in place right away before starting on your SOA journey, but that along the way, these 4 areas need equal amounts of attention if your SOA projects are to be deemed successful. In subsequent posts, I will dig deeper into these areas, along with best practices, roadmaps, etc.

December 29, 2007 at 3:15 am Leave a comment

Add to Technorati Favorites
September 2018
« Jul    

Recent Posts