The New Life of Joe – Part Three – The Users Are Coming!

By |2007-10-08T13:47:00+00:00October 8th, 2007|Enterprise Architecture|

Joe was in a good mood when he walked into the meeting with his Process Management leads for the first time.  Perhaps is was because Selina had just walked him through a consistent process for tracking and managing project information that didn’t keep everyone in “fire fighting mode” all month long.  “Orderly is good,” he used to say, and he believed it.  Ever since coming to this IT group, Joe has had a series of “rude awakenings” about their totally different way of delivering software.  This day was a good day.

That mood was about to change.

(Authors note: this is the third and final installment in a series of articles on Joe Freeflier, a new IT manager taking over a SOA+BPM driven IT group.  See Part 1 and Part 2 ).

When Joe sat down, he met his three process leads.  There was one for each business area that he worked with: Sales, Marketing, and Public Relations.  They were very different business areas, yet they maintained a very nicely integrated portal that all of their professionals, internal and external, used to do their work. 

After a round of introductions, Joe asked if they had project status available in the same portal that the shared services team used.  When they answered in the affirmative, Joe opened up the portal to look at the Marketing team’s project list, and stopped dead in his tracks.

There was one project.  The end date was the end of the fiscal year.  The budget was large enough to pay for the salary of every person in the team. 

Joe turned to Tom Rankle, head of the Marketing process team and asked for a rundown of project status and deliverables.

“Well, Joe, we don’t manage our team by project status and deliverables.  We manage by customer value points.  We have delivered 61 value points to the Marketing team this month through the updates to the advertising platform workflow and the new reporting interface for Marketing management.  That puts us right on target for delivery for the quarter.” 

“Customer Sat is running at 80% and our delivery backlog is sitting at an optimum level of six weeks of likely work.  Team morale is high, and our overtime ratio has been kept under 5% for the fifth month in a row.  Our current risks are that the new lead entry service update won’t ship in November, which would slip our updates to the event interface by two months.  Shared services has posted the risk as “yellow” so we are releasing the event update without the new service.  We will revisit it in the spring, after the big winter conferences.

I’d say we are pretty healthy.”  Tom finished by handing a small set of papers to Joe with all of these points in nice graphical format, showing steady values or steady trends. 

Joe was immediately lost. 

Where was the list of projects?  Where were the budgets and deliverable dates and change control processes?  The bug report triages, and the eternal fights over project scope? 

“Back up, Tom.”  Joe had to admit to his leaders that he wasn’t following the thread.  “I’m not sure I’m with you.  Can you walk me through the way your teams work?”

Marcie jumped in.  She was Tom’s peer, running the Sales process team.

“Let me give you some history…

“About two years ago, we were in a bind.  Our projects were always late.  Our customers were complaining all the time.  Every project was questioned, challenged, picked apart.  We would say something would cost 1 million, and the customer would say “you have half that.”  Most of the code was brittle, and team morale had gone below “low” to a kind of political viciousness… the most senior folks got to write new code, while the new guys always had to maintain the junk. 

“Then Michaela brought in the SOA and BPM guys.  We split IT up into shared services and process teams.  Our teams write the process bits.  We do workflows in the workflow management system, and we write the user interfaces.  The shared services team (or SST) provides data through services.  We own NONE of the data ourselves. 

“As a result, the stuff that changed most frequently, process and user interface, moved to our teams, while the stuff that needed to be stable (data and information management) remained with SST.  By breaking things up this way, the process teams could specialize on one thing: quick continuous improvement.

“We looked at our value chain.  You know that all of the process folks moved over here, and we had come from a lot of different traditions: Kaizen, Lean Manufacturing, Six Sigma… We all wanted to use our own process tools to solve our own problems.

“We found that the value of careful change control processes drops dramatically when the team writing the code cannot screw up the database.  We call services, and the services protect the database.  Well kinda.  It isn’t perfect, but it works fairly well.

“So we moved to an “agile development” model.  We take small teams, give them a list of features, and ask them to deliver value at the end of the month.  Each feature has “value points” assigned by the business.  We are measured on the maximum number of value points we deliver each month.” 

Marcie stopped and took a drink from her water bottle.  Then she jumped right back in.

“What we stopped doing: big analysis and planning projects.  In fact, all notions of ‘big planning’ are absent.  We let the Strategy and Planning worry about that stuff.  We just focus on delivering small, well-tuned, changes to the processes.  We measure key indicators before and after each process change. We make the changes using process management tools, not reams of complex code.  The most complex things we write are U/I code.

“These days, the users have started writing their own code using our mashup interface in Sharepoint.  It’s reduced some of the strain for small fixes and helps the customers feel “bought in” to the whole idea of using processes and services to define IT.

“So when Tom talked about his status, he was giving you the measurables that we manage by.  We care about value points, so we are always working to increase the number of value points we can deliver each month.  If we do our job well, customer satisfaction goes up.  So far, we’ve found that we can push the delivery of value points higher, but the quality drops and so does satisfaction.  So we don’t measure by value points alone.  We aim for a target “customer satisfaction rating” of 80% every month.  Tom has been nailing it consistently.

“One other thing we found is that the amount of overtime that the teams are working is a major driver of dissatisfaction.  Team members leave when you make them consistently work overtime.  So we capture the number of “forced overtime” hours per month, weight it towards the developers, and try to keep it low.  We find that does a good job of keeping morale high.  Staff turnover has dropped off dramatically since we started this plan.

“And when a service has to be changed, we involve the Shared Services team.  We collect the information and process needs, and the Shared Services team designs the service changes.  Sometimes it is simple, but often these changes are difficult, and they occasionally slip.  We find ways to deliver value anyway, which keeps our customers happy, even if we can’t deliver things in a predictable order. 

“The backlog is a measure of the amount of work that the business wants to have done.  We try to keep about six weeks in the queue at any time.  That way, if a shared service slips off the current cycle, we have useful and valuable work for our teams to do while they wait.  It is all described in terms of features, dozens of small changes that can be done fairly independently.”  Another drink of water, and she stopped talking. 

Joe took a minute to let it sink in.  What he was witnessing was a totally new way to “do Information Technology.”  These teams were not built the same way that his prior IT teams had been, and they were not fighting the same fights.  But they had solved the biggest problems that he had been facing: how to deliver value to the business customers on a regular basis.

The answer is here: combining Business Process Management with Agile Development in business-facing process teams. 

Finally Joe was getting it.  SOA is not about services.  It is about empowering a new way to deliver value. 

As the meeting proceeded, and Joe listened intently to the numbers that each team was delivering on, his mind kept wandering to his past IT teams.  “I wonder why we didn’t do this earlier?” 

He resolved to place two phone calls.  One to his replacement in his prior group, to invite him over to see this.  The other to Michaela… to thank her.

(authors note: this is the last of a three part series on Tom Freeflier.  See Part one and Part two).

The new life of Joe – Part Two – Managing Complexity

By |2007-10-01T12:27:00+00:00October 1st, 2007|Enterprise Architecture|

Selina Colander is up in Joe’s face.  Joe Freeflier, the new IT manager for the Sales, Marketing, and Public Relations IT group, called an all-day meeting for the project managers to attend a complete budget and timeline review for all in-flight projects.  Selina is not sure it is a good use of people’s time.

 “Don’t get me wrong, Joe.  You have every right to see what is going on.”  Selina was clearly frustrated, but went on explaining.  “I’d really appreciate it if you would talk to me before calling a meeting like this.”  

Selina continued, “I would have pointed out that the team already has a standing monthly meetings to discuss progress and more importantly, demonstrate features.  We call it our “retrospective.”  As for status, we have a portal with current information that is continuously updated directly from the projects.  The retrospective meeting lasts all day for you, but the project managers and developers only spend an hour in the room, and they don’t have to prepare.  They are primarily demonstrating progress, not talking about it.  If you want data, that is in the portal.”

(Author’s note: this is the second part of a series of blog posts about Joe Freeflier.  The first post can be found here.  The third and final post can be found here.)

Joe was pleasantly surprised, as he has been many times in the past few days.  Selina spent the next hour walking him through the portal and the underlying organizational structure.

“We have six teams.  They are:

  • Strategy and planning,
  • Sales Process Development
  • Marketing Process Development
  • Public Relations Process Development
  • Shared Services
  • Business Intelligence

“Everyone runs on a cadence with releases every two months.  The dates don’t move.  Each of the Process Development teams are able to deliver more frequently, but not less frequently.  The Shared Services team may deliver upgrades to many services, but they will all occur on the same day: the tenth of the month of January, March, May, July, September, and November. 

“Funding comes in through the Strategy and Planning team that allocates projects to each of the Process teams.  These teams own the user experience and all long-running business processes and workflow.  However, they do NOT own a single database among them.  Not one.  All operational data is managed, and all services delivered, by the shared services team.  The Business Intelligence team is responsible for managing the reporting infrastructure.

“This allows us to avoid a huge amount of overhead,” Selina pointed out.  “We did a study to show the amount of time that we spend in managing our projects.  We figured that good project management could reduce project risk by about 15%, but we were spending about 30% of our net time on project management, oversight, and control.  The distraction was huge.  Everyone was worried about managing the projects, to the point that we were forgetting to demonstrate progress on a regular basis.  Michaela changed all that.”

At the mention of her former manager’s name, Selina brightened.  She clearly had immense respect for Michaela, and Joe got the impression that if she could, she would have followed her when she left and moved out west.  He was really glad she had stayed. 

Joe thanked Selina and then spent the next hour alone, thinking about how he was going to take over this team.  They had created a system, not just a set of processes.  They had not been busy fixing little things about software development, like his last team.  They had started over, starting with the basic principles. They had rewritten the rules, and now he had to learn them, and quick, before he screwed up this machine by tinkering where it wasn’t broken.

What surprised Joe the most wasn’t that Michaela had created a good system, but that it moved so quickly.  It was all he could do to keep up.  Perhaps he didn’t need to. 

If he could go back in time and take a newspaper press operator from the 17th century, where a newspaper was printed one sheet at a time, and put them into a modern newspaper facility with the paper whizzing by so fast that you couldn’t see it, they would be starting over from scratch.  He wondered if he wasn’t starting over as well.

Better to learn the ropes first.  He headed off to his next meeting, this time with the lead architect for the IT group.  He was to learn about the Business Process Management technology that the process teams used. 

Something told him that this was not going to be boring…

(Author’s note: this is the second part of a series of blog posts about Joe Freeflier.  The first post can be found here.  The third and final post can be found here.)

The New Life of Joe – Part One – Off to a cold start

By |2007-09-27T12:23:00+00:00September 27th, 2007|Enterprise Architecture|

Joe Freeflier is not a lucky man.  He’s been promoted.

Oh, he wanted the promotion.  He asked for the promotion, but it is a lateral move, and he had no idea of the difference between his old job and this new, unfamiliar role.  When he came to work for the first day in the new building, in a new city, he was thrust into a series of meetings that he wasn’t expecting, where people were looking to him for ideas, not decisions.  His team filled in, but he felt like an observer, completely out of place.

His wife was so happy when he told her about the promotion.  Joe is a middle-aged guy, a hard worker.  He’d been at the company for about seven years, all of it in the IT team.  He started as a program manager, coming over from the downtown bank where he had been an IT project manager.  He’s a thin man, having lost 30 pounds a few years back.  He’s taller than average, making him look even thinner, and he comes to work in distinctly comfortable clothes. He has always kept a modest and steady approach to getting things done.  He will push for changes, where needed, but mostly his attitude is “if it ain’t broke, don’t fix it.”  If you want someone to keep the trains running on time, Joe is your man.   

Joe just took over the management of a good-sized IT group in his company.  His group is responsible for all the systems used by the Sales, Marketing, and Public Relations functions within this global multinational company.  Four years ago, each of the operating companies in the multinational had their own Sales and Marketing teams, but they were all brought together under a single executive and he worked to get uniform processes and consistent reporting.  To all accounts, from the business side, the merger was successful.

The IT path was not so easy.  Joe’s predecessor, Micheala Fling, had inherited four sets of Sales tools, four sets of Marketing and communications tools, and tools originally set up for the PR team.  The tools overlapped, created information in different structures.  Business Intelligence was a joke.  When the business teams combined, so did the IT teams, and among the 600 or so developers, testers, support and operations folks, there was no consistent “anything.”   

Micheala turned to a group of SOA architects in the company to fix the problem.  They proposed changes and she made them.  She was assertive and constant, pushing for change without pushing people out or stepping on too many toes.  She had a good relationship with the head of the new combined Sales and Marketing group and she worked to keep it that way.  She completely changed the way her IT group worked.  She used to say “When a toy is broken, you toss it.  When a car is broken, you fix it.  We are discarding the toys and fixing the cars.”  When she left, her staff gave her a toy car.  It was a good moment.

And now Joe has inherited the “fixed” IT that Micheala left behind.  Joe had spent the last four years in the supply chain IT team in Michigan.  Now he was in Ohio, at corporate headquarters, inheriting something that didn’t run the way he was used to, didn’t look like the group he had.  Micheala left to become the CIO of a midsized Restaurant company somewhere out west.  She took three of her top folks with her. 

Micheala changed a lot of things.  She hoped that the changes would last.  This was the test… “The rubber was going to meet the road.”  Could her changes be sustained?  Would the racecar that she had built out of tractor parts hold together with a new driver?  Joe was about to find out.

Fortunately, Joe has Selina Colander.  She was Micheala’s right hand, and helped set up all the processes and policies for the IT team.  When others left to go with Micheala, Selina stayed, and now she was the only thing keeping Joe sane.  Selina is not a tall woman or a thin woman.  An African American with a warm personality, and a taste for brightly colored clothes, she’s the kind of joyful person that people just gravitate to. 

Except right now… right now, she’s in Joe’s face.

(Author’s note: This story takes three blog posts to tell.  The other two entries are linked below)

Part two – Managing Complexity

Part three – The Users are Coming

Asking IT to perform Business Process Management…

By |2007-09-24T21:09:00+00:00September 24th, 2007|Enterprise Architecture|

One of the current trends in IT is for CIOs to vie for the right to take over Business Process Management (BPM) for the organization.  This means more than providing BPM tools and linking those tools to the SOA infrastructure… this means having the people who perform process management report up through the CIO.

I guess I have no problem with this idea.  Of all of the operational departments, the one most tailored to supporting a range of different skills, all oriented towards making incremental improvement in the business, is the IT department.  In effect, IT has a native skill set in providing “improvement consulting services” to the business, and process management is an improvement consulting service, so IT can provide that service with the least amount of difficulty.

That’s the theory, anyway.  Problem is that very few people in a typical IT organization have ever actually performed any formalized form of process management.  In other words, there’s a “Readiness” problem.  Most IT shops simply are not ready to perform this task.

I’ve built teams from scratch.  When I was in the dot-com space, I was called upon, time after time, to hire team members for a new team, set up their processes, integrate them into a functioning structure, and get them moving.  Sometimes I did it well.  The rest of time: I learned from experience ;-).  One thing I can tell you, it takes a lot of work to spin up a business function, even one that is well understood.  If it is a new function to the enterprise, the odds of getting it right, the first time, are truly slim.

You need to make sure that you have qualified staff, a realistic engagement process, a reasonable goal for them to achieve to prove their value, and a mechanism by which their work provides value to the business.  As the team becomes mature, their capabiliies change, and their goals must change as well.  This is difficult for any manager to put together.

But if the manager is not familiar with the work that needs to be performed, he or she has some additional problems.  A manager can hire an “expert” and rely upon them to create the team and deliver value, but if the choice of expert is not the right one for the enterprise, not the right cultural fit for the “present-day readiness” of an organization, they will not accomplish much, and the manager will not know enough to provide the backup and support the new team needs to succeed.

Result: CIO says “Build a new function” and people set out to try, and in a year, the CIO cancels the project because no valuable output has emerged. 

This story has played out in many organizations.  This is not unique to BPM.  This has occurred where the intent was to create an Enterprise Architecture team and the team started up without an Enterprise Architect.  The same is now playing out in teams that wish to create Business Process teams within IT. 

So if you are working in an enterprise that wants to take on the challenge of delivering BPM inside the IT organization, be ready for a rough-and-tumble ride.  Jump on that train only if you like roller-coasters and if all of the other criteria are met: experienced members, executive coverage, realistic goals, and an engagement process that makes sense.

It’s a truly wild ride.

Paying for SOA

By |2007-09-23T12:03:00+00:00September 23rd, 2007|Enterprise Architecture|

Once again, I’d like to return to the economic model for SOA.  This time with a comparison to other systems of payment.  I will discuss tax supported, tax augmented, tax neutral, and tax antagonistic payment systems with respect to SOA.

Long ago, in our society, we accepted the notion that government has a role to play in our lives.  For better or for worse, we allow and empower the government to tap various sources of revenue as taxation.  Those taxes are used to pay for services that we all share.  In the county in which I live in Washington state, taxes pay for services like fire fighters, police, courts, schools, universities, roads, prisons, health care for the poor, and bus services.  My federal taxes pay for other things as well.  These things are Tax Supported.

Interestingly, my taxes do NOT pay for electricity, water, sewer, or telephone.  I have to subscribe to those services, and for them, payment is metered.  I pay for what I use.  If I use less, I pay less.  I can cancel at any time.  There ARE taxes on those service payments, and they pay for things associated with the service itself (for example, a tax on my phone bill pays to extend telephone service to distant rural areas that are not economical for a phone company to serve).  These services are Tax Augmented.

There are more services available, of course, which the government doesn’t have much to do with at all.  For example, I can exercise at a local gym because I pay a monthly fee.  That gym is neither dictated by nor supported by tax dollars.  My monthly fee doesn’t include a direct sales tax (although the gym does pay taxes on that income in another way).  The business model is not significantly affected by taxes or government services.  Most commerce in the US falls into this category.  These things are Tax Neutral.

There are a small number of services that some folks actively dislike. The government wishes to discourage these services, and therefore levies taxes that are higher than other services specifically for the purpose of killing off demand for the services themselves.  These include taxes on cigarettes and alcohol.  These services are Tax Antagonistic.

In effect, the government cannot control everything and it is suicidal (to the economy) to try.  That is our capitalistic model, and for the most part, we are prosperous for it.  So how do we apply that to SOA?

If we take the same four categories: tax supported, tax augmented, tax neutral, and tax antagonistic, can we use that same approach to not only govern but also pay for Service Oriented Architecture?

Tax supported 

There are some things we all need for a reasonable infrastructure both within a company and between companies.  We need shared data models, business objects and business events.  We need taxonomies for organizing our behavior, mechanisms for governing our systems, and people who meter, control, and pay for them. 

All that overhead requires support, and no one supports it willingly.  The problem is that it is (a) necessary, and (b) uniformity is the most efficent way to handle it.  Just as having every neighborhood hire their own police force is inefficient and can lead to difficulty when a criminal crosses a boundary, having two data models leads to difficulty when you want to discover information across them.  These items should simply be paid for from general taxes.  If you are part of the business, you pay them. No questions, no options, no choices. 

I would include auth/auth services, security review, architectural review, common model planning and adoption, service directory maintenance, service failover, master data management, EDI interfaces, extranet services, and many more in the Tax Supported category of services. 

Tax Augmented

Some services are utilities.  If someone needs the service, they are happy to pay for it, but for some folks, paying that price may be difficult.  Therefore, the utility services are free-standing, metered (charge back) services.  We only put them on services that (a) the business user could theoretically choose to do without, and (b) the business can easily understand the rationale for them and is willing to pay for them.  

While it should be a goal to move some things from the Tax Supported to Tax Augmented category, you will notice that in real life, I pay for literally hundreds of services with my “Tax Supported” dollars, and about five with my “Tax Augmented” dollar.  In other words, that goal will be rare, and to intentionally move a service to this category that does not belong here will kill it.  Just as you cannot pay for public transportation through self support, (everyone who has tried, has failed), you cannot pay for Enterprise Architecture or common data models through user fees.  It doesn’t work.  Don’t try.

About the only thing I can think of for this category, in IT, is Business Intelligence, and even then, I’m not sure I would add the overhead of metering to BI.  In general, enterprises probably need to simply avoid this category altogether.  I said as much in my diatribe against chargebacks earlier this week. 

Tax Neutral

This is an interesting category and one that challenges the “economy” analogy.  This category is the area of commerce where over 80% of economic activity occurs in our society, where the government is a small amount of overhead and simply irrelevant to the day-to-day operations.  My video rental store pays taxes, but the government doesn’t decide what videos to stock, how much to charge, or what the return policies should be.  My local Walmart is part of a huge infrastructure of retail distribution.  Walmart doesn’t base very many of their merchandising decisions on government policies. 

Take care with the anology here.  The IT department in a corporation, even in a large one, is roughly equivalent to the economy of a very small town.  (In a small or medium company, you need to compare yourself to a single family household).  While, in general, there is plenty of room for many hardware retail companies in the economy, there is not room for a single town of 1,000 people to support six hardware stores.  The market becomes so diluted that each one loses money.  Unfortunately, in IT, we don’t have the ability to simply foreclose on a service that loses money. 

In IT, the folks in Enterprise Architecture are paid for, and focused on, the first tax category.  Therefore, it is easy for EA folks to ignore the relative importance of this area to overall commerce.  For the Internet as a whole, 80% of the services need to be created by business-aligned companies for the use of business customers. 

It is also difficult for business folks to recognize how small their IT division really is.  Within a corporation, where EA lives, there should be a minimal number of overlapping and competing services in use at any one time.  Just as you do not need both Cable-Model and DSL internet connections to your home at the same time, you don’t need two different IT systems to handle Customer Relationship Management.

Tax Antagonistic

These are services that are being provided to customers, but which the government wants to discourage.  In IT shops, this is an interesting one.  Getting voters to agree to punish one subset of folks is apparently far easier than getting business people to punish one area of the enterprise.  Corporations are more political than that.  Therefore, while I think this model could be useful to encourage some folks to move off of outdated infrastructure or off of a retiring platform, it is unlikely to be approved or sustained for any real length of time.  I would be surprised to find a working model for this type of discouragement in an IT organization.


The analogy of how government provides for, controls, and discourages the creation of services in an economy is a useful analogy for IT departments.  As we progress towards an understanding of efficiency, it is useful to categorize your services by the tax model that you believe will hold true to pay for them.  If you are building a service that should be provided for everyone, but it is paid for by a single business as a part of optional infrastructure, then you are likely to fail.  Just like a business paying for their own police department, tax supported services cannot be sustainably offered by tax neutral teams.  You need a tax system to pay for them.

Momentum and Inertia

By |2007-09-20T09:09:00+00:00September 20th, 2007|Enterprise Architecture|

In Physics, Momentum and Inertia are related.  In the battle for mind-share, they are as well.

If I have an idea, and I can demonstrate, in some small example, how useful that idea can be, then my idea will start to move people.  I will say “we can succeed” and they will say “I’m listening.” 

And I am at tremendous risk of failure.  If I don’t succeed, those whom I moved will not be moved again.

If I have an idea, and I cannot demonstrate how useful that idea can be, my idea will sit still.  Perfectly still.  The amount of energy needed to overcome that inertia can be substantial.  Especially if people have to choose between an idea that is “moving” and an idea that has, to date, been sitting still.

Alas, the choice.  Sometimes you need to choose between two ideas.  Sometimes you don’t.  But when it comes to ideas, perception is reality, and if people ‘believe’ that two ideas are not compatible with one another, it doesn’t matter if they really are.  People will choose.

So if you want your idea to succeed, get some momentum behind it, and cast any other idea that may slow it down as a choice, even if it is not. 

If you want your idea to fail, then let it sit still. 

An example is a powerful thing.

SOA Economic Model: Avoiding Chargebacks with Transaction Ratio Funding

By |2007-09-19T02:23:00+00:00September 19th, 2007|Enterprise Architecture|

There are still people who believe that Chargeback models work.  For example, Mark Denne argued in CIO Magazine in January:

“Chargeback is a way to put IT services in terms that businesspeople understand and value. When IT is bought and consumed like other services, IT can become a business within the business. And that is the path to true IT value.” (link)

To say that I disagree would be putting it mildly. 

I believe that chargebacks work in very rare circumstances.  In all but the rarest of cases, chargebacks not only fail to provide a measure for IT value, but they actively work against the enterprise by providing an economic incentive for the business units to build solutions that do NOT make calls to shared resources.

Now that we are entering the age of SOA, many folks are resurrecting the idea of using chargebacks as a way of incenting IT groups in large organizations to take on the burden of hosting a service that many different applications will use.  The idea is that we would measure the calls coming in to a shared service, and use those measurements to charge the users a fee for using the service.

Let me provide a scenario to make this clear.  Let’s say that Contoso Sports retails fishing rods.  They also have a division that offers fishing tours and vacations.  Two completely different businesses under one roof. 

To keep things “simple”, Contoso management created two different IT teams: one aligned to retailing, and the other aligned to travel services.  Let’s say that a SOA architect comes along and says: put a service on the Customer system in the retail division, so that both divisions can use the same “customer master.”

Sounds good, doesn’t it?  That’s the value of SOA, after all… to leverage shared resources.  Right?

The problem is the Customer system is part of the retail IT group, paid for by the Retail business.  All of the costs of developing and maintaining those services, including software development, activity monitoring, and failover support, are being borne by the Retail division, even though the Travel division use those services. 

The tempatation here, and the discussion among some SOA folks, is to simply meter the service calls.  Each call by the Retail division’s applications will be charged to the retail division budget.  Each call by the Travel division’s applications will be charged to the travel division budget.  Both divisions are using the same service, but they are not equally founded.

It is a really bad idea. 

In this situation, it is clear that the operating model of the company is either to keep these businesses seperate (with their own profit and loss statements) or to allow coordination but not enforce common processes.  Traditions grow up around those business decisions, and one of them is that the business leaders are used to dictating the scope of work for their IT teams.  The IT teams know where their bread is buttered, so they do only the work that their direct business customer wants to pay for. 

…And SOA is undone.  In the chargeback model, any feature change driven by the Travel business unit in the Customer system (travel meal preferences, for example) will not be paid for by the Retail division.  The travel division is now disincented from helping Retail with a shared service of their own. Communication stops. 

Using chargebacks, there is no incentive to develop a shared resource.  The funding model simply doesn’t allow it.

This is because chargebacks have the same effect in the SOA model as they do in other forms of computing: chargeback systems reward those people who avoid them. 

We shouldn’t be surprised.  This behavior makes sense.  We’ve seen it before.  Avoiding chargebacks is a proven strategy in life as well as IT.  We see it in the people who drive to other states to purchase things without a local sales tax, and in the departments who fled the mainframe environment, where they were charged back for each second of CPU time.

Creating a chargeback scheme to pay for a shared resource is like burning a hole in your shirt to get rid of a coffee stain: it works exactly once, and you won’t like what you end up with.

One thing that makes more sense is what I call Transaction Ratio Funding or TRF.  In the TRF model, all shared resources partake of a different funding source than business-aligned resources.  This different funding source is a fixed budget allocated to pay for shared services.  How do we get that funding source?  Either the businesses pay a flat tax to the “service hosting fund” or each IT team is simply allocated a seperate budget for shared services. Either way, the business units are NOT visibly charged back for shared services. 

In Transaction Ratio Funding (TRF), you start with a fixed operating budget.  Then, based on the ratio of transactions, the single operating budget is divided up between the teams.  For example, if team 1 hosts 20,000 transactions against their shared services, and team 2 hosts 30,000 transactions, then team 1 would get 20000/50000 or 40% of the operating budget, while team 2 gets the other 60%.

This simple model rewards the IT teams that develops shared resources, without punishing the business funding sources for creating them.

So as you consider your SOA economic model, remember this:

  • Planning to develop shared services without an economic model is planning for SOA failure,
  • Using a strict chargeback model for shared services kills your SOA,
  • Transaction Ratio Funding from a fixed operating budget rewards the IT teams that create the most shared services.

And the next time someone suggests creating a chargeback scheme for SOA services, try not to laugh.  Not out loud, anyway.

Good intentions – bad SOA

By |2007-09-13T14:13:00+00:00September 13th, 2007|Enterprise Architecture|

Joe McKendrick brings up a very important point about “building SOA” in an organization where the developers have no idea of what SOA is for, and why it should be used.  In his post, “How to ruin a SOA program and bankrupt IT“, he discusses the value proposition of ‘SOA reuse’ and one of the reasons why that value proposition is often lost in the details…

Because you need more than executive buy-in.  You need to know what you are doing.

I’ll detail the things you need before SOA reuse starts to become feasable:

  • Executive sponsorship for the cost, complexity, readiness, and infrastructure issues that ANY major IT change entails.
  • A team responsible for making sure SOA is understood, evangelized, promoted, and measured.
  • A team responsible for creating a common information model.
  • A team responsible for creating a common business event and business object model.
  • A process for insuring that projects are using the common information, event, and object models in their designs.
  • A process for improving the common models through the input and collective knowledge of the project teams.
  • Management engagement and communication so that collaboration among teams actually occurs.
  • A team responsible for creating a clear vision for how different people will integrate, what technologies they will use, and who will own the development and maintenance of the infrastructure.

Miss on ANY of these points and your SOA will not deliver the value of reuse. 

Important: There are other ways to value SOA.  Reuse looks good, but it is not the one I promote.

If you want to deliver reuse through SOA, be prepared with all of these elements.  If you cannot swing these elements, do NOT include reuse in your SOA business case. 

Don’t promise what you cannot deliver. 

Creating a constrained definition for a measurable business process

By |2007-09-13T03:32:00+00:00September 13th, 2007|Enterprise Architecture|

Ask ten business people about “the billing process” in your company.  Get specific.  Diagram it out.  You will get eleven answers. 

I had the opportunity today to ‘approve’ (e.g. “not veto”) a very generic definition of ‘business process.’  It was something to the order of ‘a series of tasks in support of a business goal.’  It was followed by examples, including something along the lines of ‘invoice the customer.’

Very generic.  I’m OK with it because it is not really meaningful.  In other words, it is so far from useful that it really doesn’t matter.  There’s no way to wordsmith something that generic and end up with something useful.

A generic definition of ‘business process’ is not actionable.  You cannot judge the quality of a business process by matching it up to such a generic definition.  You cannot tell if one series of tasks is not a process, while another series of tasks is a process, because the quality bar is so low. 

Another problem is that a process can contain a process.  ad infinitum.  There is no stated limit.  In fact, two different processes may share the same subprocess.  It’s not just an infinite hierarchy… it’s an infinite Directed Acyclic Graph!  Creating useful metrics can range from difficult to impossible.  In practice, I’d be thrilled with ‘difficult.’

If I didn’t care about business process, I wouldn’t care that the definition is generic and vague… but I’m a SOA guy… and SOA is meaningless unless you understand and manage the business processes.  Reality check: if you aren’t building your SOA to support your actual business processes, you should probably just start over. 

So business process matters, and I have a generic, recursive, unactionable definition.  What’s an architect to do?

Come up with a new definition, of course. 

Only I can’t say that I’m defining a ‘business process.’  I don’t want to be watered down with that term.  No, I’m not going to replace junk with junk.  I’m defining something more useful, more constrained, more measurable than a random selection of tasks where I can say that the last task defines a business goal…

So how do I design a defiinition?  The same way I design anything else… I look at the requirements first.

What do I want to do with these ‘better processes’ that I am defining?

Well, I want to optimize them.  I want the business to have three where it needs three, and one where it needs one.  I want to measure them, so that I can improve them.  I want to attribute them, and then compare processes on the basis of the attributes. 

So, how will I do all those things?  I’m in a large enterprise.  We have tens of thousands of processes.  How do I define the concept so that 500 analysts can collect processes, in their own business areas, and yet, when we are done, I can compare them to one another without laughing?

First off, we need some kind of stable context… something that provides common language across all business streams.  Otherwise, measurements are meaningful for improvement, but not for comparison.  Let’s use a set of business objects: things that we use to manage and track the business.  Invoice.  Sale.  Customer.  Order.  Product.  Now we can talk about all processes that impact a particular object, and we can find those processes in our database by searching for the object that is created or manipulated in the process.

Then, we need a consistent way to start and end the processes.  How about we create a list of well-defined events?  An event is a transition point where a business document changes state in a meaningful and consistent way.  Therefore, when a shipment goes out, we create the invoice from the purchase order.  The act of creation is an event.  When the customer makes the final payment on the invoice and we close it, that is another event. 

If objects are the things we manipulate, and the events are points in time, then the processes in an organization are the things that we DO with those objects either to get to an event or as the result of an event.

Oh, look, we almost have a useful definition for business process!  But we aren’t done yet.

One more thing I don’t like about the generic definition… the notion of a business goal.  The way that is interpreted, a business goal can be almost anything. It doesn’t have to be measurable or meaningful.  Let’s refine that. 

I would state that if we are to meet our objective of optimizing and simplifying our process portfolio, we need our process to be measurable.  I would say that we don’t want to support ‘any’ business goal.  We want to say that a process is completely defined if it delivers a capability that the business needs. 

So now we have the bits for a definition.  Almost everything… except a name for our new concept.

What we have defined is still a subtype of “business process.”  However, it is more constrained.  We have made it measurable.  We have given it common starting and ending places.  We have stated that it supports capabilities, not mere goals.  How about we call it a ‘normalized business process?’  

Let’s put it all together.

A ‘normalized business process’ is a measurable and ordered series of business activities that begin and end with well defined business events, and which is designed to deliver all or part of a business capability.

Now, that is a definition that only a geek can love.

On the other hand, it is useful.  We can look at a ‘business process’ and know if it meets the criteria for calling it ‘normalized.’   We can make statements to our analysts like: ‘the quality bar for business process entry into our BPM solution is that it must be normalized.’

Who knows… we might even be able to drag a few reusable, composable, well partitioned services out of these well-defined things.  And wouldn’t that be refreshing?