Patterns of IT Simplification

By |2006-05-24T21:12:00+00:00May 24th, 2006|Enterprise Architecture|

I have started to develop a first cut at a pattern language for IT Simplification.  I find that simply creating the list has helped to organize my thoughts and to think about the list of possibilities, in general.  It also helps to identify which activities should be considered ‘patterns’ and which should be considered ‘anti-patterns.’

As soon as I get a first good list, I will post an article on this blog.  I’ll follow up later with a book (perhaps). 

If you’d like to assist me in creating this pattern language, Please contact me via this blog site and I’ll get you on a distribution list for the patterns so far.


The leader of the band is tired…

By |2006-05-21T13:42:00+00:00May 21st, 2006|Enterprise Architecture|

Nothing will bring you back to earth quicker than the illness of a loved one.  As I type this, my father lays in a Critical Care Unit struggling for each breath.

If my life has an architecture, and can be understood as components, I’d have to say that the architect who helped me to build my hope, my faith, my family, and my love of all humanity is laying in that bed. 

As a child, I used to sing along with the radio.  I learned so many songs, I’ve long lost count.  One song I used to tease my father with was “Cats in the Cradle” about a father who doesn’t spend enough time with his son.  But in reality, the ribbing wasn’t fair.  The time he spent with me helped to make me who I am.

If I had to pick a song that comes closer to representing my feelings for him, it would be an old Dan Fogelberg song, “The Leader of the Band”

I thank you for the music
And your stories of the road
I thank you for the freedom
When it came my time to go
I thank you for the kindness
And the times when you got tough
And, papa, I dont think I’ve said,
“I love you” near enough

The leader of the band is tired
And his eyes are growing old
But his blood runs through my instrument
And his song is in my soul
My life has been a poor attempt
To imitate the man
I’m just a living legacy
To the leader of the band

For those of you who read this, and who believe in the healing power of prayer, I ask that you say a small prayer for the healing of Dr. Anand Malik.

A single taxonomy of business capabilities

By |2006-05-16T09:45:00+00:00May 16th, 2006|Enterprise Architecture|

I’ve blogged in the past about the value of standards.  I also have seen many efforts to create taxonomies: a standardized breakdown of some general area, down to specifics.  One that is popular with the Microsoft Enterprise Architecture team is the MS Motion Taxonomy, which is a breakdown of business capabilities created as part of Microsoft Dynamics.

A capability is a ‘container that holds people, processes, and tools needed to solve a specific business problem.’  For example, the business may have the capability of paying outstanding invoices in the financial area.  In Contoso, that may mean that a person runs a month-end report showing the list of payables, prints individual checks, prints labels, and then spends some time ‘envelope stuffing,’ and lastly updates the financial system to reflect their work.  In IBuySpy, that may mean a highly automated daily process.  For IBuySpy, perhaps some invoices can be payed electronically through EFT, so the tools select and transmit those transaction.  For those vendors that require actual checks to be printed and mailed, the tools will electronically compile and transmit a batch to a check printing and paying service.

The processes were different.  The tools were different.  But the business capability is the same.

That’s the value of a taxonomy of business capabilities.  Note that capabilities are not processes.  The process for ‘Procure Office Supplies’ can be substantially different from ‘Procure Raw Materials’ for some very good reasons.  These processes will USE specific capabilities from the business, like the ability to negotiate contract terms, and tools like an procurement intranet site for corporate employees to purchase their office supplies.  However, these high-level processes will share the need for the capability of ‘pay outstanding invoices.’

We are working on the next level beyond these business capabilities at the moment within EA, and I will blog about that later.  For now, I wanted to introduce the notion of Motion.

Just say "no" to your architect

By |2006-05-12T04:01:00+00:00May 12th, 2006|Enterprise Architecture|

A good friend once told me that she knew the exact day when she went from adolescence to young adulthood: it was the day that she realized that saying “no” to her mother was, at that time and in that place, the absolutionly postively right thing to do.

In a certain sense, the word ‘architect’ is not well understood or well defined.  Different organizations are struggling with just how much power or control an architect should have.  To be effective, an architect must have absolute decision rights over some aspects of systems design, but they must not have that right at all levels below that.

In other words, just because the architect decides that System X is composed of components A, B, and C, that doesn’t mean that the architect can, or should, design the components.  The component designer (or sometimes application designer) should design the components. 

I’m not saying that the long list of people with architect next to their name doesn’t contain folks who can do more.  Not that at all.  Every architect probably has some skill in application design. 

What I am saying is that, for large projects, or in the case of enterprise architecture, there needs to be a clear understanding of where architecture ends and application design starts.

And then, for the folks who work inside the fantastic and sometimes naieve boundaries defined by their architecture, the snooping of the architect becomes meddlesome, irritating, and unwelcome.

Let your designers shine.  Start by getting out of their way.

Consider: are there Patterns of IT Simplification?

By |2006-05-11T12:47:00+00:00May 11th, 2006|Enterprise Architecture|

Are there patterns to the IT Simplification Process?  I think there are.  To quote Christopher Alexander, father of the patterns movement:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.

As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

I believe that not only is it possible to describe the context of IT Simplification scenarios, that it would not be all that difficult to do.  The axes of data would not be “how much do your objects vary in relation to one another,” or “how do you isolate the issuing of a command from the implementation of it,” but rather something more reflective of the business environment of IT: “how do the politics and relationships of the people involved play in the decision-making process.”

You see, at the end of the day, the reason that some IT portfolios are not controlled has more to do with people than technology.  So the patterns have to reflect the array of situations that people find themselves in.

I’ll see if I can come up with a pattern language soon.  I’ll publish here first. 

Leverage, Buy, Build – the EA Simplifiation Motto

By |2006-05-11T05:44:00+00:00May 11th, 2006|Enterprise Architecture|

One of the key principles of Microsoft EA is Leverage – Buy – Build.  Meaning: if you want to invest in a capability, you have to invest in an existing enterprise system if it provides that capability (Leverage).  If there isn’t one, then you buy a COTS package.  (Luckily, Microsoft sells a number of business COTS packages, like Microsoft Dynamics, so naturally, inside Microsoft, they get first pickings), and then lastly, you build a solution.  You should reserve the decision to build something new ONLY for those situations where building it will give the company a competitive advantage.

That’s a pretty steep bar.  We set it last year, and I think we are still learning it… it is starting to completely sink in now that we are planning the next fiscal year’s IT budget.  All of the projects are being reviewed, and any that writes code has to show that the code goes to competitive advantage. 

That can be difficult to do.

The easy part is Buy.  For a company flush with cash, it is simple to buy a solution.  No one will complain about the cost, really, when you consider that a purchased package is nearly always 10% of the cost of developing it from scratch, so if there are “extra features,” no one will care.

On thing that is hard, for Microsoft IT, is Leverage. 

We have notoriously independent business units, and they don’t want to ‘depend’ on one another.  So any mention of ‘using another groups’ code’ is usually met with scorn.  This attitude has seeped into IT so deeply that it is hard to change, but change we must.

So I’m currently working on a situation where one group has a tool, and a lot of expertise, in an area where another group has a manual process.  Now, the group with the manual process wants a tool, but they don’t want the tool that already exists… Oh, no, they want their OWN tool. 

IT is not built that way.  We are more like a Japanese car company.  We build something new, and it isn’t pretty, but we improve it year after year, and after a while, it is darn good.  So, if there is a tool with some age on it, it may be the best tool in town.  On the other hand, it may be written in VB6 and badly in need of a rewrite as well.  Even so, it is better to invest in an existing tool, even an old one, that it is to create a new tool from scratch when the business capability overlaps.

Otherwise, you have this:

   Team A had old tool Foo, while Team B has new tool Bar.  Team A wants to replace Foo, but they don’t want to move to Bar because the new tool has only half the features they are used to.  Team B won’t move to Foo because it’s old and because they just finished investing in Bar, and they want to get their benefit for the investment.

This merry-go-round never stops.

So, when Team C says “I want Jellybeans” and you know that they mean Foo, make them onboard to the Foo tool, upgrading the tool to meet their needs as well as the needs of its existing users.  Refactor.  Replatform.  Reuse.

Over time, the number of tools in the portfolio drops.

And that, my friends, is the point.

Pent up Karma – 2 HD failures in 3 days

By |2006-05-10T10:35:00+00:00May 10th, 2006|Enterprise Architecture|

I guess I had it coming.  I’ve been in computing for 26 years.  The first time I’ve had a personal hard drive fail was Sunday.  I have to consider myself truly lucky.  I lost mostly family digital photos.  My last backup of the family photos was about 18 months ago, burned to CD, so there are some biggies on there, including my 15th Wedding Anniversary in Jamaica and a recent trip to India where I saw family members that I hadn’t seen in a decade.

I was out Monday with a stomach flu.

Yesterday morning, when I turned on my work PC, my hard drive failed.  That’s two dead drives in three days.

Want to know the irony?  My India photos were backed up on the work PC’s hard drive.

So I’m on a borrowed laptop while my trusty old Dell laptop, a hand-me-down from my former manager and long out of warranty, but still running like a champ, gets fixed up.

I think I’ll miss my archive of email the most.  I backed up most everything else, but it is hard to back up a file that is 5GB in size and always locked by Outlook.  Now, if I could get Outlook to automatically make multiple archive files, instead of just one, each one maxed out at the size appropriate for burning to my local CD drive, then it would have been dead easy to have been making backups all along.

I think I’ll suggest that to the Office team.  Maybe that feature will show up.

In a couple of years 🙂

Allowing feedom within the machine

By |2006-05-02T10:40:00+00:00May 2nd, 2006|Enterprise Architecture|

Our economic system works not because the central government controls things, but because it only controls the things that need controlling.  Our IT systems need to find that same sweet spot.

I’m involved in a portfolio optimization process, so for the time being, I’m spending a lot of time trying to figure out where a great many applications can be replaced with many fewer applications (hopefully, some of them will be commercial apps, and not all home-grown).

This tends to lead to a false sense of control.  If there are 100 ‘buckets’ of functionality that we identify, and then we look for overlaps within each one, it can make you think that you have a ‘final’ list, when you will never have a final list.

In fact, you never should.  Governments that control free speech have had a hard time with the Internet.  Centrally planned economies have not been able to exploit many of the innovations of the software age.  People who thought that they had a final list only effectively delay things when the list must grow.

On the other hand, standards don’t come out of thin air.  For decades, it was obvious to anyone who looked that the Canadian system for health insurance reimbursement had a serious advantage over ours… they had one standard data format for basic insurance transactions, so there wasn’t a need for expensive translation systems.  We had competition and no clear standard.  We actually had a couple of standards.

Not until the HIPAA law created a single standard that everyone must use.  That doesn’t mean that the government is regulating relationships, but it does mean that a huge source of inefficiency is removed from the system.  Now, for the first time, it is economical for software, running at a doctor’s office, to format the transactions and send them to the insurance companies directly, without the need for many expensive middle-men. (You still have overhead, but it is smaller).

I’d venture that the sweet spot, between central control and freedom to innovate lies in the standards.  Not just privacy and security, but also data integration standards, monitoring standards, and even hosting/deployment, so that the cost of deploying an application, and the difficulty of rolling one into production is so small that we can scale applications up, and down, based on actual utilization, and not based on ‘limits’ and the overhead of management.

I’d venture that the Java world is ahead of the game here, and that we need to catch up.  This cannot be a Microsoft-driven effort but it cannot be one that excludes Microsoft either.  That road has been tried.  It doesn’t work.

In that vein, I’d say that SOAP is going to have to win over REST (even though I love the basic concepts of REST).  Why?  Tools are there.  Tools to make REST work would require bits that I haven’t seen.  (If you know of a good REST library for .Net and want to convince me otherwise, please post a link).

I’d say that we need a bit more than just picking the protocol mechanisms.  We need to have standardized definitions of business transactions.  I know that Oasis has done some work there as has Rosetta.  I haven’t dug as deeply as I could have.  The end result has to be that we all leverage each other’s ideas and brains.  This has to be approachable, and easy to learn.  The transactions have to make sense.  Common sense.

Then we need to step back.  If a set of applications uses database-to-database communication to integrate… well, OK.  SOA does not equal ‘correct’ and not-SOA does not equal ‘incorrect’.  The rules don’t say ‘SOA’ but they do say ‘real-time integration using data standards.’

That’s where you find the sweet spot.  That’s where, I think, today, we need to set up our oversight.  Everywhere else, stay out of the developer’s hair.

They have enough to deal with.

What incentives lead to an optimum portfolio?

By |2006-05-01T10:16:00+00:00May 1st, 2006|Enterprise Architecture|

Ever heard the expressions: “People will do what you pay them to do.”  It literally means that they will do their job, but it also means that they will do what will help them to keep their job.  In other words, if you measure someone by how well he delivers projects “on time,” his projects will be on time, with budget or resources ignored. 

Even a balanced scorecard poses an interesting problem, because balanced scorecards work best when they are measured at division level, and not the level of a particular team.  Therefore, if one person knows that he affects only two numbers on the ‘balanced scorecard’, and his manager knows it too, then the employee’s individual scorecard is far from balanced.  He will do what it takes to make those numbers look good.

So creating the right incentives in a company has to be done carefully.  Every variable has to be considered.  Business agility, compliance, security, marketing, sales, public relations, investor relations, profit, cost of goods, all kinds of things…

So I charge that many incentive systems in a company ignore the need to keep a balanced and optimum IT portfolio.  The number of IT applications isn’t visible enough, and not enough people’s jobs depend on making that number smaller, to move your typical IT department.

Making those numbers visible is sometimes the work of a ‘special projects group’ or is simply delegated to a senior staff member, without anyone having any teeth. 

Of course, bringing in a person with teeth to support the optimum portfolio can be an expensive and devisive change in an organization that traditionally values it’s independence, self reliance, and agility.  A lot of people have to be trusted who where never trusted before.  Some people have to be consulted when they did not before.  More importantly, some people who had to be consulted before are now completely cut out.  It’s a whole new world.

But without that person to draw the fire, raise the issue, and focus the attention, it’s the same old song.