//July

An apology, and opportuniity, and a promise

By |2006-07-14T21:35:00+00:00July 14th, 2006|Enterprise Architecture|

Sometimes you find you are doing well and everyone recognizes your achievements, and other times, you have a friend or coworker point out a dumb or counterproductive thing that you are doing. 

Those are opportunities for self-reflection and growth.  Those are chances to ask “what did I get out of my actions,” and “what, in the run up to Bad Decision X should I look for as a red flag, so I don’t make that mistake again.”

The effect of my mistake: A smart, capable, and talented person, that many people know and respect, dislikes me personally because of a mistake that I made (OK, more than one).  I am a passionate believer in some principles, and sometimes that passion gets in the way of speaking with tact, showing respect for others, and simply listening better.

I could say to myself, “Nick, you don’t have to be liked by everyone” and it would be true.  But that’s too easy of a cop out.  No.  I made mistakes.  Mistakes that I can only confront myself for, because this person is not choosing to confront me directly on them.

I wish to start over with this person. Build a relationship of mutual trust and recognition.  It won’t be easy, because I’ve burned a bridge.  I could walk away, but I expect more of myself than that.  I expect integrity, honesty, tact, objectivity, business savvy and professionalism.  In short, I expect myself to model the best behavior of a good leader.

I hold myself to that standard, and I now stand in the light of my own embarassement to admit that I fell short.  I have been told that this person is aware of my blog, so if this person reads this blog entry, please accept my humble and heartfelt apology.

And to all (including myself), I commit to working harder to recognize when a passionate response is not a useful one, and to keep true to this maxim: Respect cannot be demanded.  It must be earned, first by respecting others, and secondly by respecting yourself. 

The SOA and simplification paradigm shift

By |2006-07-13T07:59:00+00:00July 13th, 2006|Enterprise Architecture|

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

  • understand what is going on, then
  • envision a new process, then
  • suggest the new process with alternatives. 

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:

  • understand what is going on, then
  • compare it to the process favored by the tool, then
  • decide where it is feasable to extend the tool, then
  • suggest the tool’s process with possible extensions. 

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.

Just when is standing your ground a Career Limiting Move (CLM)?

By |2006-07-11T01:06:00+00:00July 11th, 2006|Enterprise Architecture|

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. 

Becoming more visionary

By |2006-07-09T01:41:00+00:00July 9th, 2006|Enterprise Architecture|

These past few months have been very difficult.  Without a good vision in place for where our architecture should go, we’ve been making decisions about literally dozens of large projects: are they working towards the right goal?  Are they aligned with strategy?  Do you reflect the principles? 

To be honest, without having the destination clearly described, all those decisions are arbitrary and subjective.  We need to become more visionary.  We need to get out in front, describe the way that IT should be, and then sell that vision to the business.

That way, we are doing a lot less of arguing with solution owners about whether their vision of an application matches the principles, because we helped the business to understand what the application should be in the first place.

It’s a hard transition to make.  We don’t traditionally have that role.  The business is not used to listening (or being listened to, to be honest). 

Giving names to two different roles within Corporate IT Governance

By |2006-07-07T08:38:00+00:00July 7th, 2006|Enterprise Architecture|

There is a difference between simplifying a porfolio and creating a system of behavior that favors and produces a simple portfolio. These are different animals, as different as law enforcement and economic regulation.

Just as the police are there to remove criminals from open society, you need a set of ‘simplification cops’ who will find egregious cases of PROJECT TEAMS that want to break the rules and work within a judicial process to produce consequences.  On the other hand, just as auditors provide an air of transparency for corporations, allowing investors to make wise choices, you need a system of funding, governance, measurement, and transparency that examines APPLICATIONS with the goal of making a simplified portfolio obvious and transparent.

Perhaps this is just the more traditional seperation between Project Portfolio Management (PPM) and Application Portfolio Management (APM).  If this is the case, it is not being described this way within the company.

In Microsoft IT Enterprise Architecture, both roles are falling to our team.   From what I am able to tell from other websites, that is common across Industry.  The question I want to ask today: should both roles fall to the same person within Enterprise Architecture? 

I need to establish some terminology just to discuss the problem. 

If an architect is performing the law enforcement aspect, what term should we use?  The word “enforcer” is simply too muscular, while “architectural overseer” tends to get misunderstood as a technical activity.   We could continue to refer to the people with a generic term (Enterprise Architect) and simply call the activity a “Compliance Review.”  Right now, we use the much weaker term “Risk Assessment,” a term that I used to respect but now find ill-fitting.  For the sake of discussion, I’ll call these people “project reviewers.”

As for the transparency aspects, same problem, different clothes.  If we stick to the generic “Enterprise Architect” but call the auditing process “Funding Review” or “Alignment Review,” then we essentially devalue the individual skills needed to perform this task correctly and limit scope to a single stage of an SDLC process.  On the other hand, if we create a unique role, what would we call it:  Governance Auditor?    Solution Domain Manager?  Domain control manager?  For this discussion, I’ll use the less-than-perfect term: Domain manager.

Back to the core problem: should we seperate the roles in Enterprise Architecture?  In other words, should there be seperate teams within EA or should each architect simply wear two hats? 

To be fair… I don’t know what is ‘right’ but I suspect that, as our team matures, we will end up discovering that some folks do one role well but not the other, and that it would be very very difficult to build a program on the premise that we will create a team of unusually well-balanced folks.  Also, these people need to be assigned differently.  A project reviewer should probably be assigned to a project based on the technical stack and product mix that the project needs.  A domain manager should be assigned based on the business capabilities being delivered.

On the other hand, until we reach that level of maturity, we may not be able to seperate these roles because we could introduce communication hassles between the teams that slows us down at a time when we need to show value.

So for now, my thinking is this: while a team is young, and until there is enough work and buy-in to justify it, each EA should be a jack-of-both-trades.  This reduces the need for additional communication processes and allows one person to speak to both aspects in a particular area.  However, as a program matures, the roles should seperate into two dedicated teams, both within Enterprise Architecture.

What do you think?  I’ve made a lot of assumptions.  Do you question any of them?

The difference between creating a new app and updating an existing one

By |2006-07-06T09:40:00+00:00July 6th, 2006|Enterprise Architecture|

A team I am working with agreed to ‘leverage and extend’ an existing application rather than write a new one.  They spec’ed a new one.  (see prior posts).  Now, believe it or not, the question has come up: what’s the difference?  They reused the database.   They added a long list of new pages.  It all runs in the same portal.  Is it reuse to use the same auth/auth structure and the same shared database (used by a dozen different apps)?

Easy answer: if you are leveraging and extending an application, then you are investing in it.  Both your team and the existing users of the app should benefit.  Here’s the criteria:

  1. Your rollout process will remove the existing app from production.  If it does not, you have added a new app.
  2. The new features you have added to the system can be used by existing users without additional development costs on their part.  (In other words, they may have to change their process slightly to use a new feature that you have added, but in doing so, they don’t have to come back and modify the code.  OK to modify the config.)
  3. Any ‘shared features’ that you added, that are along the lines of features that existing users wanted, will meet the needs of existing users or can be extended to meet their needs without breaking your use of the feature… In other words, the app gives you none of the feature you need, and you develop part of the feature, and someone else needs more of the feature, it is OK to let them develop the rest… but in doing so, your part needs to be part of the overall feature.  This may require the program managers to do some negotiating. 

It really doesn’t matter if you access a database at all.  As applications in all industries move closer to SOA, there won’t be a database under most of these apps anyway.

Can we measure agility? Can we afford not to?

By |2006-07-04T10:22:00+00:00July 4th, 2006|Enterprise Architecture|

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.

Don't walk in with a problem until you have a solution

By |2006-07-01T12:04:00+00:00July 1st, 2006|Enterprise Architecture|

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.