Enterprise Architecture is a source of chaos, obstacles, and high-level fights. Any organization that has an EA team is saddled with inefficiency and cannot possibly make an agile decision. They are smart people, who can be used on other ways much more productively.
I'm guessing that this is the argument that some folks are now saying about EA in Microsoft IT. Why now? Because things have changed. You see, as a result of the leadership of our C-level executives, EA in Microsoft IT has teeth. This is a first. We actually have the ability to influence something. Not all of us have figured that out, unfortunately, but for me, I'm going gangbusters.
And the effects are startling. A very large project that has been spinning money out of control for months had defined some scope that overlapped with the applications I'm on. So I used consulting techniques (Thank you Sierra Systems Group) to get people to do what needed to be done. I saved $6M this month. I'm feeling pretty good. If EA could do that as an annual average per app architect, we would save the company $120M per year. Personally, I think that is conservative. I think we could save up to $200M per year if we really got going.
So, why would some folks be saying bad things? Because our process involves oversight. We come in to a project at key points to review. Good architects do more than 'seagull' the project (Fly in, make a lot of noise, crap all over everything, and fly off) but I'm sure that, in some cases, we are percieved that way. Not every team is aware of the need to cooperate with EA, so their only experience would be limited to the oversight role.
Better teams would work with their architects as the project goes along, touching base on key decisions and generally inviting him or her to major project status meetings. That way, if a decision was made that is not good, the architect knows before 'review-time' and a minimum of resentment is generated.
On the architect side, we need to be "bringers of solutions," and not "bringers of obstacles." So if I say "no" to one thing, I have to say "yes" to something else.
It's common sense. I know, but it was hit home for me again this week as I had to pour ill-will over a very visible project for a decision that they made over a month ago... We are all kicking ourselves for not seeing it earlier. That said, I have a really good team of passionate people who want to succeed. We will write up a solution over this weekend, and clean it up on Monday, and present it on Wednesday.
I need to be the bringer of solutions.
If I don't, I'll deserve that criticism.
In Enterprise Architecture, we spend a lot of time caring (strongly) about agility. How do we reform IT (people, process, portfolio) so that the business can more rapidly adapt to strategic change?
From a process perspective, one way to approach the problem of agility is to make it more likely that a project, once chartered, will actually deliver business value, and not just rearrange the deck chairs. That means, of course, that we need to ask the business to put a measurable value on the things that they do. The result is scorecards and dashboards and BI reporting. All excellent stuff.
But there is an underlying capability that is directly stated in the problem statement, but frequently lost in the wave of operational data: system agility. In other words, what people, process, and portfolio measurements are needed as part of our IT scorecard, so that the systems themselves become more adaptable, configurable, and user-self-service-empowered?
And here is where we can inadvertently fail to measure important things. Here is where scorecards need to be carefully composed to address the problem. Measurables drive process improvement efforts like Six Sigma, so failing to measure a key measurable means two things: improvement in agility will be inadvertent, and decisions that reduce agility will not receive proper scrutiny.
Bottom Line: We must be able to measure agility.
To measure it, we must define it.
What is agility?
Is agility measured by the time it takes to change a business rule? How come it takes longer to change some rules than others? What can we do to find and reduce the root causes of delay in the ability to change a business rule? Heck... how do you define a business rule?
Is agility measured by the time it takes to deliver a new business capability? Why can I deliver some capabilities quickly, and others take years?
Are some capabilities 'bigger' than others? Does the relative size of a capability factor in to the time needed to change? How do we measure the size of a capability?
These are hard questions. Have you answered them in your scorecard?
Some may say: you cannot define change because you cannot predict it. Therefore, preparation for a specific change is pointless. It creates bloated designs and expensive software.
I agree. But I am not trying to predict a specific change. I'm simply observing that change, as a force in and of itself, is a normal part of business life. It is not constant: some years we change more than others. Change is driven by many things, both internal and external.
Agility is our ability to respond to change gracefully and with few flaws. If we, as IT, build processes and solutions that don't take change into account, the cost of avoiding agility will vastly exceed the cost of embracing it.
I say that we can define agility, measure it, and improve it. In fact, we must.
In order for SOA to deliver in its promise, we need to change the way that the requirements analysts approach problem solving. This is critical. I can prove it.
When I gather requirements from the user, I can't just ask "what do you want?" The question is meaningless. I have to
In that process, I am making assumptions about what constraints to apply to the process. Is there anything I cannot do? The only constraints are to reduce costs or automate manual processes. That is not enough.
When a company decides to implement a commercial software package to solve a problem, a different approach takes place. It goes like this:
In order for SOA to work, in order to gain flexibility and agility and reuse, we need to follow this second process, even if we are solving a problem with composition of existing services... even if we are not purchasing software... even if 100% of the components are home grown.
THESE STEPS MUST APPLY.
It is this second process that assumes that the company already has an answer. It is this second process that requires teams to solve their problems by FIRST considering whether an existing answer is "good enough" and SECOND considering the cost of extending it. We will never achieve simplification without doing this first.
Training the requirements analysts to think this way may be the single largest shift towards SOA. It may be the most difficult thing to do. Yet, I am convinced that this is the only way to accomplish it.
Proof: The project I've joined is staffed with truly intelligent, earnest, hard-working people with good intentions. However, they followed the first process above. They developed a "shiny new" process and that drove the needs for a "shiny new" tool, even though the company already had a couple of tools for the exact same thing. They never ever considered looking at those tools, or constraining their solution by those tools.
We must constrain our solution to existing tools first. Those tools don't have to be something we are buying. They can be, they must be, the things we already own.
SOA depends on creating services that will be reused. Unless we choose to reuse them, then that promise of reuse will never be fulfilled.
I took my kids to a regional amusement park called Silverwood in Idaho. We had fun, but it's a small park. Smaller than most Six Flags parks. Two nice roller coasters. Brand new water park attractions. All in all a nice way to kill two days.
We took one of my son's friends along, so I had four kids with us, all between the ages of 8 and 12. Kids at that age are playful and social and still enjoy spending time with Mom and Dad, so it was a good family experience.
Things I learned:
All in all, the cost of tickets: $350. The cost of hotel: $650. Four days with four kids: priceless.
Yes, we have an acronym for it. CLM -- any action within your scope of control that you could do, maybe even should do, but which you are likely to pay consequences for, repeatedly, for about the next five years.
Sometimes I wonder if testers get pinged on Sev-1 bug reports? I doubt it. MS has a very healthy testing culture.
On the other hand, if your job isn't 'Tester' but your role includes "review" of someone else's deliverables, let's face it... either you are a tester or you are a noisemaker. A tester is someone who points at the emperer and says "No Clothes" without fear of reprisal. A noisemaker says "Odd choice in clothing, sire. We think your traditional garb is better."
In other words, a tester is allowed to simply point to the problem, without having to consider if it will delay a project or cost additional resources to address. When a tester points out a defect, it is never a CLM. When a noisemaker does, it might be.
Today... I envy testers. I'm still standing.
Simplification reduces the cost of maintenance. The business probably doesn't want to think about it, and they really don't want to pay for it. However, in many situations, IT has no choice. By reducing the number of applications, reducing the number of redundant data stores, making data paths simpler and more measurable, and driving for more consistence in non-value-add processes, the company can reap real benefits in cost savings.
However, simplification requires a couple of things. It requires project teams to change processes and code. It requires support teams to manage the data shifts and all the ripple effects. It requires release management coordination to make sure that new features and simplified systems do not conflict.
Where does the money for that come from? This requires the business to pay for this work. It requires that IT have staff and resources to dedicate to it.
Think of it like aircraft maintenance. When a jet airplane is being repaired, it has to be pulled out of service... for a day or two or ten. But the airline cannot simply cancel the flight because the aircraft needs a routine tune-up. The airlines have some capacity, in terms of aircraft seats, set aside so that they can allow the aircraft to be inspected, maintained, and returned to service.
So when an airline decides how many flights per day to set up, it has to plan on a certain amount of excess capacity just to cover the number of planes needing service. It does not apologize for these costs. The cost of your airline ticket includes the cost of maintaining other aircraft.
And you don't complain. Why? Because you want YOUR aircraft to be working when you get it.
Similarly, the IT department needs to have excess capacity, in terms of project teams and hardware space, to cover the costs of simplification.
This requires real leadership to pull off, but it has to be done, especially in larger IT departments where there are many developers writing code. In these environments, the amount of overlap is substantial, so the benefits are large.
So for every five project teams that you can use in business-requested maintenance or new features (airplane flights), you need a sixth team for IT driven simplification (aircraft maintenance). That team needs project managers, product managers, developers, testers, release and code management, and support members. Full out teams. The business does NOT get to drive the efforts of these teams. IT does, as needed, with the guidance of Enterprise Architecture or the EPMO.
Without this capacity, you will never be able to solve, or fund, Simplification. It's a cost of doing business.
Last note, when I say "Simplification", I'm not talking about consolodation. Sun is spending a lot of time talking about the savings that a company can earn by moving software from multiple servers to a single Sun server (lower power, lower rack space costs). That is consolodation, and it is not specific to Sun servers. You can get the same benefits from any server consolodation.
This reduces ongoing run costs, but not the costs of maintenance. In fact, it may increase the costs of maintenance somewhat by placing more complexity on a single server and decreasing the redundancy.