When "Quick Win" is an oxymoron

By |2007-04-13T04:32:00+00:00April 13th, 2007|Enterprise Architecture|

I know of an excellent project that was spun up in a hurry to write a small amount of really tough code and roll it out.  It was a “quick win” project, so named because you can get value out the door quickly. 

I say “was” for two reasons. 

One: the quick part is over.  It is going into production.  Now comes the really slow part: owning it.

Two: the Win part is over too.  It’s value has been demonstrated. It reduced cost or increased capability as expected.

The problem with a “‘quick win” project is that code, quickly written, requires quick replacement. 

Now that this code is in production, it is time to purchase a commercial package, for less money, and greater capability, to augment it.  The alternative is to slowly, expensively, add one feature after another until the IT group has written so much code that they will hold on out of pride, even though a commercial package is (a) available, (b) less expensive, and (c) more fully featured. 

You see, if you invest in a quick win, you have to settle for the quick replacement that follows.  Otherwise, you are taking a success and letting it sink into failure.

Relinquish control… trust the Wiki

By |2007-04-12T10:27:00+00:00April 12th, 2007|Enterprise Architecture|

The oddest thing I’ve ever seen, really, is when folks ask for collaboration, but then create a process based on heirarchy and closed-door deals.  I see it in nearly every team I work with or on with one exception.  I guess I’m just ‘sold’ on the Web 2.0 stuff, especially Wiki, which I discovered about five years ago and immediately fell in love with.

The point of the wiki is not to oppose heirarchical control, but to augment it.  Heirarchies are really good at making decisions stick.  One person is accountable.  That is very necessary.  On the other hand, they are pretty bad at getting data to flow upstream, which means that the decisions are not always based on the best information.  Decisions are the ultimate GIGO exercise.  If you don’t have the best information, you can’t make the best decisions (excluding lucky choices).

The one exception I mentioned is for the dev team on the project I’m working on.  They are beginning to ‘get’ wiki (after I’ve foisted a couple of wiki’s on them).  It takes time, and trust, to allow others to edit your ideas.  It also takes a certain culture of respect.  That said, wiki sites are fairly good at things like “roll back changes” so if one person provides a comment that someone else doesn’t like, it vanishes.  In order to keep it from vanishing, the original author can come back and just retype, but what usually happens is that the original author returns and writes something a little more “well thought out” and a little less “divisive.” 

That kind of ‘group feedback to the individual’ is pretty cool, and I don’t know of many other places where it works in a business setting, especially for IT folks.  We are used to taking pride in being technically correct even if it is difficult for others to hear.  Making your message palatable is a hard lesson for some folks, but a necessary one, and the Wiki serves as a good ground for that.

So the next time someone suggests that you write up your practices, your standards, or even your project documentation, consider using a Wiki.  If you don’t have one, get one.  They are free.  Sharepoint has one.  There are dozens of different shareware wikis, at least a couple for every platform.  They are not good for documents that capture ‘agreements’ but for everything else, they are a great way to change the way we communicate.


Architecture… Is it code, or is it data?

By |2007-04-11T09:51:00+00:00April 11th, 2007|Enterprise Architecture|

Some dev folks are all about the data.  Others are all about the code.  Somehow, we build and improve systems that combine them. I work with many teams, so I get an interesting view.

One team that I work with has a fairly weak data modeling practice. The number of data models on the wall is pretty small.  This is a team that works the code.  When I talk to folks about architecture, most of the folks listen for code.  In this team, new data requirements tend to ripple through the systems.  On the other hand, reuse of code is everywhere and their libraries are sweet.  They cope with their data by creating as few databases as they can.  Data integration isn’t a problem when you have only a handful of data sources.

Another team, that I deal with on occasion, is all about the data.  Everything starts with a professional, clean, concise data model.  Databases are everywhere… dozens of them.  That team will then partition the components based on how they access and use the data, not on what the system needs to actually do, which leads to its own set of problems.  Reusing anything they write is nearly impossible.  Every business rule requires system-specific code to pull it out of a database and use it. Their systems have been designed by allowing the business to partition them.  In other words, the business basically decides which system should host a feature, even if it makes no sense from an application or reuse standpoint.

Still another team I work with is all about the products.  They care more about how to squeeze every feature they can out of the technology they currently have than anyone can imagine.  In Microsoft, we get free access to all our products.  We also get access to products under development, which is risky sometimes.  This group manages (somehow) to pick off nearly every new technology and sign right up for implementing it.  Functionality is a function of what you have in the product stack, not what you need for the business.  While their customers have grown used to ‘making do,’ the relationship between business and IT is based on control, mistrust, and fear, not collaboration and common goals.  Data elements are managed in the structures they have, but they are nearly never integrated.  Reuse is a fantasy, propogated by the few and ignored by the rest.

Architecture is the binding force that can break each of these teams free.  We need the best of each world. 

We need strong data models to decide not only ‘what’ widgets goes in a system, but ‘how’ we will control, manage, and distribute widgets through our infrastructure.  We need seperation of concerns at the database level, to keep complexity low and allow for reuse.  We need excellence in data element identity, so that any application can find the ‘widget’ in the data environment, regardless of what application created it.  We need excellence in data schema, so that everyone has a consistent way to interpret the information on a widget without having to dig rules out of the source system.   

We also need strong application models to decide what capabilities are ‘local’ to a widget, and what capabilities are ‘meta’ or require the coordination of multiple widgets.  We need to be able to scale the functionality without scaling the database.  We need to be able to encapsulate business rules in small, easily found, and easily changed modules that can be reused with near-abandon wherever they are called for.  We need to be able to produce, quickly, a completely new application from existing run-time components without generating a complete regression test against the infrastructure.  We need to insure that we limit the number of ‘points of failure’ so that weaknesses in hardware, networking, and databases can be overcome to provide a consistent and stable experience. 

We need to develop and maintain a deep and thorough understanding of the technology base.  The products must be selected correctly and carefully, and used to their best extent.  The highest of standards must be maintained in privacy, security, and management.  The networks must work.  The data storage systems must be reliable.  From a development standpoint, the infrastructure is the fundamental source of both power and constraint. 

When writing systems, Architecture is all three.

So if you are going to stand up an architecture team, include real strength in each.  Get men and women who care, and who are not afraid to argue with you, bargain with you, and brainstorm with you about the Application Structure, the Data Model, and the Technical Infrastructure.  Build a team.  Then build excellence.

Self Improvement in a team

By |2007-04-07T10:18:00+00:00April 7th, 2007|Enterprise Architecture|

What is the correct responsibility of the team to improve the skills of each team member? 

As in many businesses, Microsoft has a formal process for employee annual review, including a six-month “check up” called a “Mid year career discussion” or MYCD.   We just finished the MYCD process for most folks.

It is a time for introspection.  It is a time to address the stuff you truly screw up in.  A good manager points out the bad things you do and honestly offers to help you improve.

I think back to the time that I spent as a manager.  As painful as ‘review’ is for the employee, it is truly tough for the manager because of not only the time involved, but also the energy and effort it takes to go through your team, examine everyone’s strengths and weaknesses, and dedicate yourself to the success of others. 

The fly-in-the-ointment is that the manager may not be qualified or capable of offering any good advice or resources to help address the needs of one or more employees.  We look to the manager to be an expert in career advice, and that’s silly.  (It’s one reason that I stopped being a manager.) 

In my current role, I have no direct reports.  I have a team that I collaborate with. 

When I look at the team that I work with, the people are a varied lot.  “You get them as they come” is a good way to put it.  Some more skilled than others, usually in completely different ways.  It leads me to ask: what is the correct responsibility of the team to improve the skills of each team member?

More importantly, can the team be the place where an employee can get the support, mentoring, and reflection that they need to improve themselves?  Can a set of messages be equitably and fairly conveyed to allow team members to support each other in key ways, to make the entire team more successful?

I have questions today.  No answers.  But I think there is something worth investigating there.

Microsoft, BPEL and Open Standards

By |2007-04-04T08:43:00+00:00April 4th, 2007|Enterprise Architecture|

We are frequently criticized for not supporting enough open standards.  Honestly, I think it’s negative hype.  MS supports a long list of open standards, some of which we created, some of which we didn’t.  This one is cool: BPEL.

When business analysts write down business processes, they use diagram tools.  In the Microsoft stack, we’ve had Visio, but that tool is a general purpose diagram tool, not really a niche tool for any particular niche (much as we’ve worked to extend it).  As a result, in the Business Process Engineering space, MS has fallen behind major players who produce tools that MAKE SENSE to business process people, and even provide some great analysis capabilities.

However, if a company uses one of these tools, and then wants to share those process flows with developers, it gets weird.  In a pure MS world, the developer would have to re-envision the workflow using the WF Designer in Visual Studio.  If that seems like extra work, it is.  It’s wasteful and the models can easily become out of sync.

Enter BPEL.  John Evdemon has done a good job of keeping track of this space for us, and I refer you to his excellent blog.  BPEL is an open standard for sharing Business Process workflows between tools, and now WF can play in that space.  This means, of course, that we can now skip the step where a developer “interprets” the workflow created by a business analyst.  We can import it directly.

This is so cool.  There are excellent tools out there, and through this simple feature, we allow the users of all of those tools to feed WF-based systems with workflow.  I encourage all my architect collegues to become familiar with BPEL 2.0 and how WF will use it, and spread the word: WF is enterprise ready.

Never flip the bozo bit… on your customer

By |2007-04-03T09:12:00+00:00April 3rd, 2007|Enterprise Architecture|

This bit of advice is now considered “old hat” but I believe “Don’t flip the bozo bit” came out of a book by Jim McCarthy in his book ‘Dynamics of Software Development’.  (corrected)

The intent of the advice, of course, is to say that a development manager shouldn’t decide that a particular team member is “not with the program” and write off their advice, for any reason.  That is because people can be right, or they can be wrong, but they are rarely consistently one or the other.  A person can be “bang-on right” about one thing, and “dead wrong” about another, and a dev manager has to keep an open mind.

We sometimes don’t follow that advice when dealing with our own customers.  That is a shame.

My prior post engendered a response from a member of the “non-IT” community that complained that, when their department approached IT for a workflow solution, they got some bits about roles and authentication, but nothing for workflow.  They are solving the problem without the help of IT.

While I cannot speak to that situation, because I’m not familiar with all the details, I can certainly draw a parallel to a situation that I have seen while working at a different firm.

In this firm, most of the data was locked away in mainframe computers.  There was no SQL interface to the data, only CICS screens, which could be easily consumed by PCs using screen scraping techniques… as long as the fields didn’t move around (a hazard with screen scraping systems).  So, the business and IT got together and decided to develop a special set of CICS screens that could be used by programs.

These screens would just have data, in a simple stream, so that programs doing the “scraping” wouldn’t have to do a lot of work to find the field.  They don’t “move around.”  The scraping is simple and the interface would work.  The business teams were delighted, because they could write their own little applications to automate tasks, while the IT department could stop being a bottleneck for small business-level requests that never seem to rise up the stack.

Months went by.  The dev team decided to release two CICS screens that contained a wide array of data, from dozens of other screens.  Security for the fields became a problem.  So did all the back-end cost needed to join all that data, because in the past, the screen scrapers would only ask for the data they needed… now they got everything, and the cost of using the interface was rising.  Documentation was sparse and not openly shared.  Add to that, as the business changed the main screens, someone in IT thought it would be a good idea to change the ‘scraper screens’ to stay in sync.  There was no way to request a particular version of the screen or even to find out what version was being displayed.

As a result, the business value was lost in implementation.  IT blew it.  Here’s the funny part: they blamed the business customers.  They said that the business customers had asked for too much data, that it was too complicated to maintain, and that they complained when the screens were updated (they never complained when the ‘human usable’ screens were updated).

After a year, the project was scrapped.

So what happened?  Well, the point of the project was lost in the implementation. 

When I interviewed the developers of those CICS screens, it emerged that the business analyst (requirements gatherer) had “flipped the bit” on his customers.  The dev team had five people, in the business, that they normally worked with to get requirements for this screen.  One of the most annoying and persistent folks had insisted on things like version numbers and a stable interface, but he also insisted on all the data coming back on a single screen.  They called him “Mr. Noisy.”

At first, they listened to Mr. Noisy, but as it became clear that returning all the data on a single screen was becoming expensive on processor time, they ‘flipped the bit’ and stopped listening to him altogether.  All the other good ideas, about a stable interface, version numbers, standard field identifiers, open documentation, etc, that he was pushing for was ‘flipped’ as well.

The rest of the business users were easier to work with.  Eventually, Mr. Noisy went away and the project delivered junk, and the project was killed, and no one cared.  Mr. Noisy was the person who wanted it in the first place, even though he had convinced others that they could benefit.  No one saw any benefits.

Classic failure.  Why?  Because the one person who had 20 good ideas had one lousy one, and the dev team didn’t have the guts to push back against the bad idea but honor the good ones.

Moral of the story: Ignoring “Mr. Noisy” may be easier, but you could lose good ideas and possibly the business value of the project.  Keep your noisy customers close.  Listen to them.  Tell them why their good ideas are good and their bad ideas are bad.  Only then can you actually deliver value.