soabloke » it-management

Top Down Procurement

Saul Caganoff — Tue, 20 Apr 2010 09:57:10 +0000

Imagine you have a unique business offering that needs IT delivery and support. There are two approaches you can take to do this:

Bottom Up:

Determine your business requirements.
Choose an application which you think best fits those requirements.
Spend a lot of money customizing the application to better fit your requirements and integrating it to other systems.
Deploy the application.
Hope you support the business adequately within time and budget.

Top Down:

Map out the business processes to support your offering.
Determine the services required to support the business processes.
For services that already exist – do nothing.
For new services – build or buy applications to support those services.
Implement the processes.
Hope….(ditto).

Often “bottom up” is the default approach, even though “top down” can be more cost-effective and provide a closer fit to your business requirements. However “top down” comes with some risk, because most off-the-shelf applications are built to support “bottom up” acquisition. You might end up having to do integration anyway.

As the world moves toward service portfolio management rather than application portfolio management, vendors move towards offering services rather than applications and the “top down” approach will become more widespread and more viable. That will be a good thing, I think.

Leverage and Vantage

Emergent Architecture

Saul Caganoff — Wed, 19 Aug 2009 00:23:43 +0000

Dion Hinchcliffe has written a nice blog entry “pragmatic new models for enterprise architecture take shape“. This resonates well with some of the things I’ve been saying about how enterprise architecture needs to be enabling rather than blocking:

“In recent years enterprise architecture has been moving from a discipline that provides top-down, a priori technology blueprints to the business side to one that articulates key, strategic possibilities and only the most critical high-level constraints (such as security standards) and then operates as a conductor, promoter, problem solver, and evangelist across the organization through the vehicle of a cohesive community to co-develop needed solutions.”

(my emphasis added). And:

“Invariably, the best architecture I see comes naturally from self-organizing thought leaders in an organization that seek each other out and collaborate on common solutions to their problems. Rather than the us vs. them mentality of old-world enterprise architecture, there is only an us mentality. Instead of prescribed standards, designs, technologies, and tools there is real [two-way] consensus and immediate buy-in.”

And as with all Dion’s posts there is the cool graphic. I especially like the two downward facing arrows – “community leadership” and “guides”:

The article is well worth reading but I think there is a large element of wishful thinking here. It paints a good picture of how enterprise architecture should be, but I fear we are a long way from this nirvana. Much of the vision depends on a fundamental change in organizational culture. Businesses that recognise the value of an “emergent culture” will naturally have an “emergent enterprise architecture.” I don’t think it will go the other way around. Emergent enterprise architecture will not survive in or be able to change a top-down corporation.

In the long term, those companies with the right culture will support emergent enterprise architecture and thrive on IT success. Those companies that don’t will cede their IT resources to others. Those who can do IT will do it on behalf of those who can’t. Cloud anyone?

Martin Fowler on Humane Registry

Saul Caganoff — Wed, 10 Dec 2008 05:38:22 +0000

I have long held the belief that governance is more about effective communication than anything else. To quoth my own horn:

…what is needed is a shared understanding of the architecture principles, frameworks, standards and best practices used within your organisation for providing and consuming Services.

How do you ensure that this shared understanding is
a) communicated effectively,
b) understood and
c) implemented by all.

A corollary of this view is that any governance tools ought to support this communication as their primary function. I’ve often thought that a wiki would make a pretty good governance tool. Good to see that Martin Fowler agrees. He describes an interesting “Human centric registry” based on a wiki with just enough automation to remove the drudgery. Martin describes the principles of the registry as:

People develop and use services, so orient it around people

Don’t expect people to enter stuff to keep it up to date, people are busy enough as it is.

Make it easy for people to read and contribute.

(sorry UDDI, thank you for playing).

The 10 most frequent lies told by IT consultants

Saul Caganoff — Fri, 09 May 2008 07:16:02 +0000

From Bob Cringely, the 10 most frequent lies told by IT consultants:

1) “This can only be accomplished through a large custom development project.”

2) “Of course your data is safe.”

3) “We’ll need a day or two for optimization and debugging.”

4) “Yes, we’ve done this before. There are several companies using this product (or technology). They really like it.”

5) “Server consolidation and virtualization will save you money.”

6) “Storage consolidation and virtualization will save you money.”

7) “The upgrade (or change) will be seamless and will not affect production.”

“The upgrade (or change) will be transparent to users.”

9) “Yes, we tested this thoroughly before installing it.”

10) “If you install Tivoli it will solve all your support problems.”

No related posts.

Leverage and Vantage

Saul Caganoff — Tue, 11 Mar 2008 22:58:31 +0000

I’ve been busy with customer projects for the last few weeks and hence the lack of postings. In this post I want to touch on some conversations about top-down versus bottom-up approaches to SOA.

This is a pertinent question because there is still a communications gap between the “business” and “IT” in many (especially large) organizations and as a result SOA initiatives are often driven from the IT side of the fence with little support or even understanding from the business.

There is a fundamental “chicken and egg” problem with SOA. It won’t gain support from the business unless a business case can be made…but conversely SOA payoffs are elusive without business support. Faced with this situation, many IT architects who want to develop an SOA approach are forced to try to conjure the egg out of thin air and hope that a chicken will hatch. The danger with this approach is that rather than gain an SOA you may end up with just a bunch of web services.

Two key facilities that an SOA initiative needs are leverage and vantage. Vantage to see where you need to go, and leverage to push the organization in that direction.

SOA is all about providing services to support the processes of the business – typically across organizational silos. There is a need to understand all the processes and their requirements – now and for the future. This visibility needs a vantage point “above the fray”. A point from where you can see the processes in their entirety. Without this vantage point you risk building the wrong services, or building services for the wrong processes or not anticipating future process changes. Moreover this vantage point must be experienced from the point of view
of the business – not just IT. So the question for an SOA initiative is “who in your organization has this vantage?” You may be lucky and have complete visibility from the IT cockpit, but that is rare. In general no one person has this vantage and it generally resides across different roles and people. Hence the need for some governance process to capture that vantage into a SOA plan.

So let’s suppose you have this vantage and want to execute on an SOA initiative. SOA is primarily about sharing – shared services built on shared resources using shared standards. Without sharing you wont get the SOA pay-off. But sharing requires communication and cooperation. Leverage is required to reconcile conflicting priorities in terms of requirements, schedule, funding, and resources. There may be some organizations where all these conflicts can be reconciled within the IT department, but I haven’t seen any yet. Typically resolution is required at an organizational level above the participants – that is the prime purpose of organizational hirearchy. Hence you need the appropriate leverage to get everyone moving down the SOA path.

While the type of issues your SOA initiative will face are fairly general, the specific issues and their resolution will be germane to your organization. This means that the place you will achieve the right level of vantage and leverage will be different for your organization. You might be lucky enough to work in an IT department that has the appropriate leverage and vantage, but that is rare. More likely you will have to go higher up to get these facilities for a successful SOA. This is the essence of the “top-down” approach to SOA.

I guess the “middle-out” approach might be characterised by “figure out how much leverage and vantage you have access to an scope your initiative from there.”

The SOA Governance thing…

Saul Caganoff — Wed, 13 Feb 2008 04:36:33 +0000

SOA Talk ask if there is a better term than “SOA Governance”. The “Big Brother” connotations of SOA Governance have bothered me for a while but I don’t think there is a need for new terminology.

At design time, what is needed is a shared understanding of the architecture principles, frameworks, standards and best practices used within your organisation for providing and consuming Services.

How do you ensure that this shared understanding is
a) communicated effectively,
b) understood and
c) implemented by all.

This goes way beyond technology solutions and encompasses the overall development culture. Tools can help – but they should be an enabling framework rather than an enforcing roadblock.

Update: Todd Biske has recently also blogged about the relationship between governance, tools and culture (here and here).

SOA Executive Insight Report

Saul Caganoff — Thu, 17 Jan 2008 08:39:16 +0000

An important force helping to push SOA up the slope of enlightenment is the sharing of knowledge, experience and validation from SOA “doers” rather than marketers. The SOA Consortium is one body set up by the OMG to try to help this along (although caveat emptor the consortium is sponsored by a bunch of vendors).

I read through the SOA Executive Insight Report which reports on the discussion between a number of CIOs who all apparently have extensive SOA experience. There are a couple of interesting comments of note.

The CIOs…

“expressed concern regarding the current industry focus on wire protocols and products, rather than business value generation and the necessary business and IT changes for sustainable SOA success. The industry – vendors, press and practitioners – must “elevate out of the technical weeds” in order to engage the business on SOA.”

This was written in April 2007, but is still so true today. In particular the arguments of ws-* versus REST are not about SOA and should not be confused with the viability or otherwise of service oriented approaches to providing functionality and value to IT users.

The second interesting comment is:

“CIOs noted the lack of common practices for

service versioning,

the complexity of testing shared services with multiple consumers,

the challenge of identifying mission critical services,

the reinvention of chargeback procedures,

blind spots in capacity planning, and

the need for ‘real-time releases’.

The CIOs want best practices for these issues. Specifically, they mentioned an ‘ITIL for SOA’.”

These are issues that I see creating many challenges for SOA adopters and there are no simple solutions. These are also issues I have run into in my own SOA work and I hope to write about them in the future.

One other comment on the SOA Consortium web site. There are a number of SOA “case studies” which is great to see, but very disappointing once you drill into them. They lack any real “meat.” We need more than just a few bullet points…details are needed on what challenges they faced and how they overcame them. As they stand the case studies look like a selection of vendor power-points.

More SOA Metrics from the Blogosphere

Saul Caganoff — Fri, 11 Jan 2008 03:51:36 +0000

I recently found another set of SOA metrics on IT-Director.com. There is a gratifying degree of overlap with the metrics that I discussed recently. I particularly like the categorization into different metrics for different roles in the organization.

From his observation of innovative organisations, Smith has come up with 10 possible service delivery metrics, grouped by organisational area:

Corporate Metrics:

Revenue per service;

Service vitality index (the amount of revenue from new services over the last 12 months as a proportion of total service revenue);

Management Metrics:

Number of new services generated and used as a percentage of total services;

Mean time to Service Development (MTTSD);

Mean time to Service Change (MTTSC);

Service Availability;

Project Metrics:

Service reuse;

Cost of not using or stopping a service;

Service Development Metrics:

Service complexity;

Service quality assurance based on systems-level tests that examine the behaviour of service-oriented use cases across possible choreographies.

The original post contains some further discussion of the metrics.

I suggest that Service Reuse also has a “management” role since that is related to return on assets which is a key measure of success for your SOA initiative.

Revenue per Service is another interesting one and I’m not clear if this refers to “external revenue” or “internal revenue”. There is an argument for measuring both.

External revenue reflects the value of services to supporting overall revenues to the business. I suspect it would be difficult for most organizations to attribute external revenues to the service level. Revenue would map to a particular business process which in turn is supported by services. There would then need to be some way to allocate a contribution to each service on this basis.

Internal revenue would reflect the value of the service to internal business operations and could be counted via some metric on how often a service was used.

SOA Metrics for Continuous Improvement

Saul Caganoff — Sun, 06 Jan 2008 23:25:50 +0000

Following from my last entry on metrics I do think it is important for metrics to be used to monitor and demonstrate continuous improvement as part of an SOA initiative (or any IT initiative, for that matter).

Key metrics should be built into your SOA organizational infrastructure so that they are maintained and reported as a by-product of your day-to-day SOA activities. So even though I don’t believe there is (currently) any absolute measure of SOA success, what is important is the relative measure and how that changes over time – “am I getting better at this?”

So what are some good metrics? ROI is the most fundamental metric. The reason we embark on an SOA and the reason that the business pays for it is to improve the bottom line – make IT more cost effective and more responsive to business needs. ROI is important to your CEO, your CFO, your CIO and your shareholders. The problem with ROI is that it can be difficult to measure…especially when dealing with less tangible measures such as opportunity cost around time-to-market (agility). What we need are some good proxies for ROI which can be easily measured on a day-to-day basis.

Cost to build a new service is a good metric. If services are provisioned as a project, then it should be relatively easy to measure the total cost of delivering a new service to the business. You should normalise this metric against the complexity of a service. Split services into simple, intermediate and complex if that makes sense. The total cost per new service should decrease over time.

Elapsed time to build a new service is also a good metric to monitor agility. This is a simple form of Nick Malik’s agility metric. Basically we want to ensure that we are delivering new services faster by leveraging off our SOA infrastructure. One of the commonest complaints I hear from businesses everywhere is that IT takes too long to deliver. As with the cost metric, you probably want to normalise against the complexity of a service in some way.

Service utilization is another good measure. Once a service is provisioned, how many business processes make use of that service? What is the daily throughput for the service? These can be objectively measured by service monitoring tools. But note that counting business processes requires some thought to meta-data in your service infrastructure.

Services with a high utilization will indicate what is of most value to your organization. Conversely, services with a low utilization may indicate a low value service or a function which shouldn’t have been made into a service in the first place. Perhaps your governance processes around service identification and prioritization could be improved here. Alternatively, services that used to have high utilization and now have low utilization may indicate obsolescence where it makes sense to retire that service.

Average cost per service, Delivery time for a Service and Service Utilization are easily measured, fundamental metrics for your SOA. There are other SOA costs that should also be accounted for.

Average cost to run a service is important. Add up the BAU costs (hardware, software, maintenance, monitoring, administration, power consumption etc) of your services infrastructure and divide by the number of services you are running. This measure will often be high when you start out and have few services, but should reduce over time.

Governance cost should also be tracked. What is the cost of the governance processes that you put in place to evaluate service candidates, prioritize and plan your services road-map. Usually this cost is made up of time and effort for the people involved in SOA governance. The governance cost per service will initially be high, but should hopefully reduce over time. [This raises an interesting question...how do you measure the effectiveness of governance in order to justify the additional cost? It is difficult to separate out the contribution of governance to the overall SOA benefits.]

These measures can be combined to give an overall ROI index for your SOA. If you can estimate the total business value of your processes and divide by the total cost of the services that support those processes, then you get an aggregate ROI measure

Finally a warning to be careful about how you define a service for inclusion into these metrics. True re-usable services come with a higher price-tag in terms of planning, governance and infrastructure, but the idea is that re-use amortizes the cost over multiple business processes ending up with a positive ROI for the service. There are probably many integration points/projects which do not justify treatment as a re-usable service. These “point integrations” should not be included in the SOA metrics because you are not comparing like for like.

SOA Metrics, Projects and Organizations

Saul Caganoff — Sun, 06 Jan 2008 10:55:35 +0000

In Measuring the agility of an SOA approach Nick Malik proposes a metric to verify the “agility” claims for SOA. While I applaud Nick’s efforts to create some objective measures for the business case around SOA, I think that Nick’s proposed methodology falls down in step 2.

Nick proposes you apply the agility metric to two projects – one SOA project and one non-SOA project – and then compare the results. Hopefully the SOA project would demonstrate a higher agility measure.

The basic problem that I see is that “SOA-ness” is not a property of a project, “SOA-ness” is a property of an organization.

SOA is more about the general organizational approach to delivering projects and involves things like:

The organizational structure that defines and delivers IT projects (including the way projects are planned and funded).
The technical standards, frameworks and best practices that have been put in place and refined over time.
The SOA assets (Services) that have already been delivered and are available for re-use on any given project.

If we wanted to compare metrics from two different populations to determine if SOA truly does provide benefit, then we would need to compare at the level of organizations. Find two different organizations – one that has adopted an SOA approach for IT management and one that has not. Then find which is the most agile or which has the better ROI or whatever favourite metric you have.

In practice I don’t think this is realistic. Embarking on a true SOA approach requires significant organizational change and that requires something of a “leap of faith” for the early adopters. Over time, hopefully the benefits of SOA will become apparent. Until then, I keep my eyes open for studies which can demonstrate SOA benefits and best practices – but I won’t hold my breath because as with many of these things, “your mileage may vary”.