5 Signs Indicating Need for Service Governance

August 21, 2010

The word ‘governance’ seems to conjure up all sorts of negative images for IT folks – needless bureaucracy seems to top that list. However, without lightweight governance, SOA and systematic reuse efforts will fail to achieve their full potential. Can you spot signs that indicate need for governance? I believe so and here are five:

  1. Every project seems to reinvent business abstractions that are fundamental to your problem domain. No sharing or consistency of information models – this will be painfully evident when projects are happening back to back and your teams seem to be running into overlapping data modeling, data definition, and data validation issues.
  2. Directly linked to above – is service definitions seem to not reuse schemas – i.e. each service has a unique schema definition for a customer or product (or some key object from your domain) and your service consumers are forced to deal with multiple conflicting schemas.
  3. Legacy capabilities are leveraged as-is without mediation – increasing coupling between consumers and legacy systems. Tell tale sign here is if you see arcane naming and needless legacy data attributes sprinkled all over service interfaces.
  4. Services seem to have inconsistent runtime characteristics – new service capabilities are added without regard to performance requirements – issues tend to manifest in production where users or entire processes/applications get impacted to service behavior.
  5. Business processes bypass a service layer and directly access underlying data stores – if you have seen a business process invoking several stored procedures, doing FTP, publishing to multiple messaging destinations – all from a monolithic process definition that is a clear sign that governance is non existent.

These are few signs but key indicators that services are being built in a tactical fashion. In a follow up post, will expand on how governance can be leveraged appropriately to address these issues.


Building Assets Iteratively – An Example

April 13, 2010

Building reusable assets iteratively helps your team in several ways: reduces technical and business risk, reduces time to market, and increases the odds of real-life usage across applications. In this post, I wanted to walk through an example of iteratively building a reusable asset. Our task was to create a suite of services for providing core data such as customer data and product data to various internal applications. To support these services in production several non-functional capabilities were required. These capabilities needed to be reusable across services – i.e. we didn’t want to develop something that would only work with customer data and not product data. Note: this effort was before mature SOA governance tools started to appear – so if you are thinking “why did they build this?” – because it didn’t exist at that point in time 🙂

Iteration 1: Simple logging to log requests, responses, errors

Iteration 2: Configurable logging – ability to change logging levels without restarting the service container

Iteration 3: Ability to enable/disable service capabilities via a service interface – a web service end point that would turn on/off services (we had business reasons to support this capability)

Iteration 4: Toggle service capabilities via a web interface – integrated functionality from Iteration3 to be able to perform the toggle via a browser-based front end application.

Iteration 5: Get statistics about a service capability – usage metrics, distribution of error codes, etc. was available for every service capability.

Iteration 6: Enable/disable HTTP endpoint – to enable/shut off access to a HTTP port that was listening to service requests.

Iteration 7: Enable/disable JMS endpoint – to enable/shut off access to a JMS queue that was listening to service requests.

Iteration 8: Toggle transport endpoints via a web interface – integrate functionality from iteration 6 and 7 with our web based console application.

Iteration 9: Get usage statistics filtered by consumer, date and time, and various other fields.

Iteration 10: Integrate usage statistics querying with web based console application.

These iterations were executed alongside business functionality – the interesting aspect of this – and something that all agile methods emphasize – is that we learned from real-world service usage and troubleshooting in production. We didn’t have to dream up requirements – as we gained deeper knowledge of how services function in production, the needs emerged naturally. Coupled with reviewing logs/production statistics and interviews with service consumers we were able to prioritize the supportability tools that were needed.


Software Reuse Quick Tip #22

November 6, 2009

Tip #22 – Ensure Service Capabilities Stay Effectively Decoupled

The rationale for contract-first services (as opposed to code-first) is to effectively decouple service capabilities from needless implementation-specific, vendor-specific, and data-source specific realizations. You put the initial service capability out and ensured that the contract is decoupled – no legacy system specific details, no database-vendor or technology platform-specific attributes are present and your consumers are happy.  So, are you done? Well, no…because we all know that the technology environment, business requirements, regulations, and continuous innovations are the realities of modern development. You have to be careful not to succumb to these pressures and tread towards needless coupling. It is very easy to add one more attribute or element to your service contract and not pay attention to tight coupling being introduced.

As you add new versions, introduce enhancements, and make bug fixes take care not to introduce needless coupling. You can tie in code reviews – focused specifically around service contracts – to ensure this happens as part of your overall governance strategy. I will post detailed examples for this quick tip in a follow up post.

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

tweet this add to del.icio.us post to facebook


Driving Systematic Reuse With MDM

September 17, 2009

I have been espousing the need for pursuing systematic reuse in conjunction with other initiatives such as SOA, BPM, object oriented programming, in a agile manner. Master Data Management (MDM) aims to manage core enterprise data as a strategic asset for the organization. It impacts data quality, data governance, data services as well as business processes that access/update core data assets. MDM can play an important role in your systematic reuse efforts as well. How? Let’s think about the intent behind MDM – the primary driver is to reduce costs and enable revenue generation using enterprise data assets such as customer data, account data, product data etc. These goals not only require technology but also processes and governance.

You can use MDM to drive systematic reuse using the following ways:

  • Opportunistically create fine grained and coarse grained data services as dictated by your business needs. Your MDM data store will evolve as the strategic data store for all business processes eventually. But, while you get there, you will have to incrementally and iteratively build out a service inventory. This service inventory will be reusable for multiple projects and initiatives while giving you the flexibility to change underlying data structure and processing logic. More importantly, you will build service capabilities that you know at least one client will use.
  • While developing data services built on top of your MDM solution, your information modelers and analysts can re-examine the domain and update data entities, relationships, and business rules. All this information will guide your canonical data models plus can help in building object libraries and domain specific language toolkits. Basically, you are reusing the analysis efforts for service and object capabilities. You can even use XML-object data binding tools to generate classes from XML schemas and vice versa. A more likely outcome of such an exercise is also identifying refactorings to the existing codebase. Your service capabilities and object models may not reflect the business domain accurately and you can make those changes in conjunction with business deliverables.
  • Related to the point above, you can develop reusable decision services including specific rule sets that can not only fulfill MDM based processing but also for other problems in your domain. If the entities and rules are getting reused you will go a long way in reducing costs when building business processes.
  • In an earlier post I talked about the importance of easing integration for consumers. MDM will streamline data processing and improve data quality. But it also presents an opportunity for you to create easy to use integration toolkits for consumers to get the improved data. If you know marketing applications consume core data in a certain way, would it not make sense to make consumption as easy as possible?
  • Integrate data access/update policies, data quality checks, as well as use of specific data governance workflows into design and code reviews. As MDM practices mature in your organization you will get smarter about how different applications, processes, and external partners need to interact with your MDM data store. In essence, you can mandate interaction via MDM data via standardized, managed interfaces. This over time will surely drive reuse of data services as well as data governance workflows and business rules.

This list isn’t exhaustive but my intent was to illustrate how MDM can help your systematic reuse efforts. The key message is basically – don’t pursue reuse in isolation with other initiatives.

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

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: