From Tech Platform To Managed Service

June 13, 2016

There are a lot of teams building platforms – whether for an internal organization, for a public cloud, or somewhere in between. Question to ask yourself – are you focused on providing a managed service?  or are you too focused on only being a technical platform? These questions are key because it is all about understanding customer priorities, focusing on customer success, and being paranoid about all aspects of the offering and not only the technical bit.

Don’t get me wrong – without the technology underpinning the platform doesn’t work, it doesn’t exist, and there isn’t any foundation to stand on. However, the purely technical bit is necessary but not sufficient for your platform to succeed. Shift your perspective and viewing from the vantage point of offering a managed service. You will appreciate that there are additional elements that are equally important:

  • How do customers sign up to use the platform? what pre-requisites exist and at what point in the process do they have to address them?
  • How is the platform supported? is there a dedicated support team, documented and communicated procedure for escalating production issues? how are incidents, follow ups handled?
  • What is the release management philosophy for the platform? is there a published schedule and is that honored? what about critical bug fixes and their roll out time windows?
  • Are you promising any specific uptime / availability numbers to customers? do you have business rationale for these commitments (i.e. non-functional requirements aren’t being assumed…)?
  • Will you charge your customers for platform usage? if so, how will you capture usage statistics and how will that translate to billing units? what changes have to be made in your software stack to account for usage exceeding limits/quotas, usage during critical operational time windows, usage during business critical events, etc.?
  • How will your current and prospective customers find out about new features (including ones that are beta/early-release vs. those that are available for broader use)? is there a committed testing procedure that promotes a feature into the platform?
  • How do you certify that the platform does what it is supposed to do – iteration after iteration, release after release? do you have tests and test evidence tying customer facing features and their availability against a particular platform version under test?
  • What is your philosophy on public APIs? do you have / plan to provide language bindings against your public REST APIs for instance? if so, who owns that and who keeps that up to date as the underlying platform goes through revisions?
  • How is capacity managed in the platform? is there an overall resource pool? or are their customer-specific runtimes? how can you accommodate unforeseen spikes in demand? have you tied new customer provisioning and platform inventory management?

The point of the above isn’t to list every possible facet of what you need to think and plan for. It is to illustrate the fact that providing a managed service is more than just having a technical platform.

Add Transports Iteratively For Service Capabilities

July 14, 2009

You can add transport bindings to your reusable services iteratively as necessitated by project needs and timelines. A service can start out getting consumed over HTTP, and then support additional ones such as HTTP-S and JMS over time. The key is to not place transport logic in your service capability. This will give you a great deal of flexibility in adding and supporting new transports.

For example, your service can be initially consumed by a user interface application via request/reply SOAP over HTTP. Day 2, you might have a backend process that consumes the service via asynchronous request/reply SOAP over JMS. This should be a graceful extension for you if there was nothing in the service logic specific to HTTP or synchronous request/reply.

In essence, you are decoupling request processing, service business logic, and response handling:


Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Reuse connectivity components across your product line

April 15, 2009

Connectivity components such as database connection pools, messaging broker connection pools, HTTP thread pools, and others should be decoupled from your business logic components and managed separately. If you are using an application server that provides connection pooling out of the box this will be a non-event. But if you have applications outside an application server that need pooling functionality encapsulate them as separate components. Provide configuration options so each application that leverages these components can customize it. If there is code that couples connectivity and other types of logic actively refactor them out. Most importantly, when these components are in a production environment provide a means to reset or reinitialize them. As Michael Nygard points out in painstaking detail in his book Release It! this is going to make the difference with stability and availability. From a reuse perspective, if the components are stable and robust it saves time for the consumer when leveraging the asset. Most importantly, this will increase trust in the quality of these assets which is key to ensuring your investments into reuse don’t go wasted.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Standardize error codes for reusable error handling

April 14, 2009

Standardize error codes across reusable assets so that multiple assets can report errors in a consistent manner. If error codes are consistent, how you to chose to log them or react to them can also be standardized across the product line. If each reusable asset gives you a unique set of error codes it makes it difficult for dealing with them. Standard error codes themselves could have a naming convention depending on where the error occurred, which component/module/service the error originated, and type of resource impacted by the error etc. I like to use a dot (“.”) notation when reporting errors – e.g. when the  XYZ module in ABC product cannot fetch a database connection the error code is: DB_CONNECTION_ERROR. You can have stack trace and error location to pinpoint where the error occurred but it is important that all database connection errors across your reusable inventory use the same error code. If we need to retry the connection, or notify a database support team, or whatever remedial action needs to be taken can be initiated across the product line using a single mechanism to handle errors.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

%d bloggers like this: