Un-Open Open-Door Policy

Have you ever noticed how corporate-speak can completely rot a manager's mind when they start to believe their own words? The oxymorons and contradictions just start to grow as fast as kudzu. One of my colleagues recently met with his new manager and hastily scribbled down the following quote:

"I have an open-door policy ... but just because my door is open doesn't mean it's OK to come in and talk to me. Schedule an appointment, first."

Of course, this same manager's calendar is always blacked out as "busy" throughout the whole day. It's like the fellow just switches on the "auto-cliche" mode when he walks into the door in the morning. Worse yet, he only has 6 direct reports and he has aspirations of injecting some agility into the SDLC. Clearly a classic example of management-by-in-flight-magazine (mbifm) or hamburger management.

Enterprise-Speed Blogging

About 1.5 years ago, a tiny group of dissidents visionaries (the victorious get to re-write history) established a stealth wiki and also started using it's blogging capabilities. This was only the first. Exactly a half-dozen of us have been continuously blogging, internally. Apparently it was a shock to some internal auditors, lawyers, HR and senior execs when they had the original idea of setting up an internal, corporate blog, that one already existed. To their credit, they didn't shut down the stealth blogs.

Anyhow, the point of the post is that it took the enterprise about 1 year from idea to roll-out. Aside from the obvious conclusion that most enterprises are as agile as a cow on skates, the fact that it took people in the enterprise a year to overcome FUD, find/allocate resources and devise a management scheme for a non-revenue-generating internal resource. All this for a simple piece of blogging software that I'm sure any of my readers could have set up and running in an afternoon. That's all the time it took us to set up the original wiki and blog, too. Getting the installation officially blessed took the other 364.5 days.

Proponents of open-source software, Ruby and other dynamic languages, methodologies, etc. need to take into account it takes time to overcome FUD even in light of working proof.

Architectural Role & Career Progression

Simon Brown has started an interesting discussion about career paths for architects. To code or not to code is one of the thoughts, as is the timing of architecture transitioning from being technology-oriented to business-oriented. Business-Oriented Architecture (BOA), anyone?

Reasons Why IT Sucks

I was enjoying reading through Neil Hepburn's post about SOA without IT governance until I came across this:

"If you're going to switch to building things using a SOA approach, you're probably just going to start building services for new applications. Those applications in turn will be funded by projects, which will be managed by a project managers' whose responsibilities are to the success of the project, and not for the success of IT infrastructure. As the PMI likes to remind us: "Never goldplate". Full disclosure: I am PMI certified. Okay, so what does this mean? This means that while it is possible to build re-usable services. In all likelihood, they will be built for a specific application."

In this case, IT governance is being used to treat or prevent a symptom - redundancy. The underlying cause has been completely glossed over. An application is the wrong level of abstraction for a SOA. Regardless of how hard we try, applications are incredibly static. Business demands flexible logic and processes which we have wrapped up in very inflexible applications.

Instead, the creation of services needs to be driven by the business domain model. There should be no duplication of behavior and data in the business domain model and that becomes the spring-board for service development. Domain models are surprisingly resilient. They also don't change much over time in an industry. The business is all about how that domain model is used. Each service is a publicly accessible implementation of a domain object (remember what an object is: behavior and data). The application is reduced to the (often) ad-hoc collection of rules and sequences that bind a collection of services together to form a business process.

IT sucks because we focus on how the domain objects and logic are packaged as an entity. After all, we can box up, shrink-wrap and sell entities. We focus on building-to-last instead of building-to-change.

SOA Economics

I was going to add this as a comment to Alastair's recent post about SOA The Economics of Agility but, I wanted to expand on my comment. I think he has unearthed a very interesting point. When the up-front costs of setting up a SOA properly are examined, it's not that different from the same up-front costs the telcos faced when they first started building their networks almost a century ago. A huge infrastructure was required to be put in place well before the last mile could actually be delivered (switches, hubs, cables, directories, sub-stations, human routers, etc.). Maybe we should look to how cellular/wireless telecom has flourished in places recently where there was no classic telco infrastructure in place. There was certainly a master plan for deployment and management but, installation was incremental and flexible. Surely if deployments for entire countries can be logically designed and planned, we ought to be able to do the same in an enterprise.

A SOA without at least a registry and repository quickly devolves from a small collection of services to a P2P mess. Once a P2P network reaches a certain size, it basically becomes unmanageable. However, P2P networks flourish because they are so easy and cheap to set up. It's the classic pay-me-now or pay-me-later argument. If we can find the line between keeping the agility of a P2P network vs. the cost-effective management capabilities of a SOA for a particular organization, the move to a full-fledged SOA not only makes economic sense, it makes obvious sense. The problem is, there's no recipe; however, it's not a mystery, either. That's how the wireless carriers grew, right?

IT Literate or Business Illiterate

Andy Mulholland asks, "What is the role of an IT department when the users are IT literate?" That's certainly a valid question but, it's not nearly as threatening as the current, widening gap between business and IT. The question we still don't have an answer to is, "What is the role of the IT department when its employees are business illiterate?" Have we just just decided to keep living with the status quo and hope for that magic day when the users are IT literate? I guess that's really not a problem for most of the CIOs and pundits because they will be long retired when that day comes so, it will be somebody else's problem.

Should Architects Code?

If a picture is worth a thousand words, one concrete example is worth a thousand abstractions. I have to attribute inspiration for the previous sentence to Jack Greenfield when I heard him talk about software factories. One of the observations he has made about design patterns is that they are great at describing how but poor at describing when. This leads nicely into the topic of whether or not architects should code. Let's take a look at a couple of situations.

Should architects write production code? That's probably not a very effective use of their time and skills. One of the hardest parts of becoming an architect is to realize that coding is no longer the primary job. A transition needs to be made from being the one who is concerned with building something right to being the one who makes sure the right thing is built. However, one of the jobs of an architect is to show others how to build something right so, be ready to dig-in and pair-program with someone on the team so that knowledge and experience is passed on.

Getting back to Jack Greenfield, one of the topics he has written about is that developers that are either junior or new to a team lack context. They need to learn the domain, patterns to solve problems in that domain and finally, when to use those patterns. One way to accelerate this is to provide worked examples? Again, templates are great but, they are only as useful as patterns. Knowing when to use a design pattern within a domain is the kind of knowledge and context and architect needs to supply. Provide worked examples, not templates.

One of the other duties of an architect is innovation. Not only is keeping current important, keeping in touch with what the next big thing might be is just as important. Testing new products, evaluating frameworks and just trying out new ideas all need hands-on time. Often, who else has the time to innovate? When it comes time to talk to people about a new idea, get feedback and even sell the idea, that's when a page or two of some clearly written examples are worth a thousand powerpoint slides.

If architects don't code, are they still architects? Sure but, perhaps not as effective as they could be.

How To Think About The Agile Enterprise

It seems that the technology marketing buzzword factories have been hard at work, because a bit of web research reveals a whole slurry of terms:

Adaptive Enterprise
Agile Enterprise
Business On-Demand
Real-Time Enterprise
Zero-Latency Enterprise

The contrarian in me smells snake oil. It seems that whenever the IT industry gets it's hands on a concept, there ends up being way too many solutions to solve very few problems. When consultants sell methodologies and vendors sell products that claim to provide an agile enterprise, that's a pretty good indicator of the difficulty of the goal. If it's truly that easy, how come more companies aren't agile?

Let's do ourselves a big favor and completely forget about technology, methodologies and processes. Frankly, I think these three things are actually impediments to agility as they are most commonly understood and applied. They are actually all related.

The biggest impediment to agility is inertia. Most enterprises are about as agile as a supertanker. Actually, that's not quite accurate. Ships have freedom of movement, it's just that the movement can be very slow. It's possible to be slow and agile. Most enterprises are as agile as freight trains. That's more accurate. Trains have lots of inertia and they travel along defined paths; there are no steering wheels in locomotives. However, large companies can be steered in different directions, albeit slowly. Most enterprises are as agile as a cow on skates. Not only does it not want to be on skates, once moving, it does not want to change direction for fear of crashing. Aside from the comic value, that's a pretty useful description.

The second is data-centric thinking. For those of you who have never worked in a large organization, making a change to a database or data model is almost impossible. There are legions of people dedicated to protecting the sanctity of the schema and are human-shields to change. We love static, permanent structures. This mindset is a major part of the problem; agile database is an oxymoron. The fact is that data is useless without interpretation. Just look at any database table with several columns of foreign keys to see what I mean; without interpretation (joins), the data in the table is meaningless. The whole goal of normal-form analysis is to maximize the use of joins, thereby rendering raw data even more meaningless. In most cases, agility requires changes in use and interpretation, not the data structure.

The third is our fondness of ceteris paribus models. We like nice, sequential, step-by-step models where only one variable changes at a time. Those models are great for teaching/learning but are useless for operations. It's impossible to run even a lemonade stand with ceteris paribus models. We need to have models that help manage dynamic, multi-variable systems that are often non-sequential.

We build systems using the second and third concepts even though we know they are no longer working well and we consistently apply the first concept in the face of external forces. Going forward, we talk about loose-coupling, re-use and process management, etc. Aren't all of those just more, simple models re-cast into agile roles (and just as likely to fail)? Perhaps, that's all the vendors are selling because that's all they can build?

Instead of loose-coupling (which still implies assembly), perhaps we need to think in terms of mixtures, aggregates and ad-hoc federations?

Instead of processes, maybe we should focus on events and variability management?

Instead of re-use and general purpose, one-size-fits-all components, possibly the focus should be on more multi-purpose components that can be easily adapted within a more limited domain?

Maybe the core problem is that we think of an agile enterprise in terms of what we already have built or know how to build? Maybe the answer is to truly understand what needs to be built and not recapitulate solutions?

Too Much Abstraction Or Ineffective Perspective?

The Pragmatic Architect writes about The Neverending Abstraction. My knee-jerk reaction is that abstraction is perfectly valid when contained within the domain of the problem but, doesn't need to be expanded to deal with every possible case outside of that domain. In other words, don't over-engineer the solution.

Then I started thinking about the possible root-cause of this common behavior. Perhaps it's not the layers of abstraction that are the problem but, instead it's the depth of the taxonomy. What happens when a Vendor becomes a Customer? What happens when a key person at one customer, who has a deep history with your company, changes jobs? As much as we hate to admit it, very few of us practice true OO because we have had deep taxonomies and Nth normal form drilled into us since elementary school (kingdom, phylum, genus, species, etc.). The result of this is that we cast the majority of our objects solely as data containers, not interactive (behavior-based) information sources. This has two side-effects. The first steers us towards designing class hierarchies based on attributes, not behavior. The second is that our objects are too big. Let's look at the Customer object in The Neverending Abstraction.

This is a situation many of us have encountered, where the object is a Customer and it contains a field called name. Let's think about this a bit. How many different ways are you asked about information concerning your name? How many different ways do you ask your customers about information concerning their name?

1. first name
2. last name
3. middle initial(s)
4. middle name(s)
5. christian name(s)
6. full name
7. surname
8. generation
9. title
10. salutation
11. prefix
12. suffix
13. first four letters of your surname
14. nickname

That's at least 14 methods, not including possible formats (last name first, etc.). Doesn't that constitute it's own object? When a Name needs to be applied to a company, it's easy to add common name, legal name, d.b.a, etc. Now, on to the Customer object. You are a customer of many companies or, are you? We tend to define ourselves by what we do. However, we do many things. Does that imply we have a clone for each major task we do? Of course not, we are a Person object that happens to be performing a specific Role. That should guide our thinking about OO abstractions.

The second possible root-cause is computer science education. Even when introductory courses are taught with an OO language, the first thing that we learn (in the case of Java) are the primitives and the second are control structures. We still haven't shed a half-century of procedural baggage. I can sum this up with one, very simple (American-centric) example. Hands up, how many people have used (in Java) an int for a zipcode? How would you address a package destined for Portland, Maine?

Try abstracting behavior, first. Then, worry about the attributes. Isn't the mantra, "Program to interfaces?"

H1-B vs. Off-shoring

Why do we need to increase the pool of H1-B visas? Since cheap talent/labor is the goal, why not just move the work off-shore? Or, is the pent-up demand for H1-B visas a tacit admission that having bodies in-house is far preferable to off-shoring for a number of reasons?

Dr. Frederick Young has another insight about H1-B visas expressed in U.S. Students Discouraged:

"Those who want to increase the number of foreign workers are looking for cheap labor and aren't helping our national security. If they want more good IT professionals, let them pay better wages!"