Zen and the Art of IT Leadership

Watch This Space

2008-06-29T18:32:00.007-05:00

Well, I guess I have stuck to my own advice of doing less in order to do more. So well, in fact, that I haven't blogged in, well, nearly seven months!

That's not exactly what I had in mind when I made that last post, but it's funny how life catches up with you when you least expect it, and all you can do is give it your attention. Throw in both professional and personal preoccupation, and the next thing you know, half a year has elapsed.

But, hopefully life and work are close to finished with the curve balls and I can get back to blogging. As those of you who have read my blog have noticed, my blogs aren't just quick missives, usually, and take some time to craft (if you don't mind my using the word "craft" liberally). To kick things back off, I'm going to start a focused series of posts on Enterprise Architecture. The series will look roughly like this (though the final lineup might change - they aren't book chapters, after all, and I do manage at least a little bit of free-wheeling with these things from time to time):

Enterprise Architecture's Reason for Being, and in Some Cases, Reason for not Being
Key Focal Points for Enterprise Architecture - Communication, Quality, Consistency, Cohesion, Strategy
Finding Balance in Enterprise Architecture - Accretion and Erosion, Jigsaw Puzzles and Handcuffs
Some Practical and Practicable Advice for Enterprise Architects
Power Struggles, Personality Clashes, Misalignment of Management, and Red Herrings - a Sampling of What Goes Wrong

So, there it is, I've committed to several more posts. Watch this space...

A New Kind of New Year's Resolution

2007-12-31T08:42:00.000-06:00

Here's a somewhat unconventional thought for the coming year. While everyone else is making new year's resolutions to do more, make a resolution to do less. Note, I'm not saying accomplish less.

Lately I have been reading "Six Disciplines for Excellence" by Gary Harpst. He reminds his readers in the chapter on deciding what's important that "The essence of strategy is deciding what not to do."

Support for the IT department saying no is not always strong in many businesses. It takes a foundation of trust, transparency, and a spirit of interdependence to make this possible in some cases. And, frankly, this should be a goal of any IT leader to begin with. I have found that support not just for saying no, but more importantly for pursuing avenues of work that best serve the health of the company at the expense of delaying taking up an otherwise perfectly good cause, goes up tremendously when everyone at the table shares the same vision for where the company is heading and is confident that IT's role in realizing those goals is sound and on target.

In the spirit of goals about which IT is concerned, there tend to be two major categories in my experience: Striving Goals and Thriving Goals.

Striving Goals are the goals that tend to traditionally get set by the core of the business - revenue goals, production goals, profit goals, growth goals, etc. These may or may not have input from IT when they're established, though hopefully they do if they are at all related to an IT function. If these are in place for the coming year, the question then becomes one of how to reach them. IT's concern is doing its part to help meet these objectives. It's when these goals don't exist, or when IT simply can't realistically meet them, that friction occurs. Still, if everyone sits at a table and discusses the goals openly, these issues can usually be overcome (even if it means saying no to a goal). In the best scenarios, the decisions will be made by the group, not soley by IT leadership digging in their heels.

Thriving Goals are those sometimes poorly-understood (by the business) and somewhat nebulous activities that take place deep within the bowels of IT. Some are an easy sell (virtualization projects with tangible ROI comes to mind), while others (identity lifecycle management, or updating aging technology) are quite a bit tougher. These can be tough to put a concrete ROI to in some cases, especially if you lack metrics to do so honestly and accurately. To make matters more difficult, they also often cut into the time available for tackling those Striving Goals. But, as someone who cares about both the long-term health and wellness of the assets and resources you provide stewardship for, and as someone who cares about growth and retention of your most valuable resources, your employees, it's imperative to build support for making time to focus on these goals as well. Which means carving some time out to focus on the Thriving Goals, and choosing not to work on those Striving Goals, so that your house stays in balance.

In Harpst's book, he says that his small, growing business achieved more by doing less, by cutting out the activities that weren't truly important. Anyone can choose to do everything requested of them. It takes discipline to begin focusing people on identifying the very most important objectives (VFOs, or Vital Few Objectives, in Harpst's book) and to resist the temptation to attempt to fulfill all the requests that come in the door.

But, by choosing to be more focused on fewer things, choosing to harness people's energy and creative talent rather than dilluting it across many tasks and activities that drag on indefinitely, and by balancing future-seeking Striving Goals with Thriving Goals that ensure your technology and human foundations thrive not just next year but for the next decade, 2008 can be the first of a succession of best years in your company's IT history.

I look forward to writing more about Striving and Thriving Goals in 2008. In the meantime, Happy New Year to my readers. I wish you fulfillment, happiness, good health, and balance in 2008.

Is Your Software Throw-Away?

2007-12-21T00:34:00.000-06:00

It's a simple question: Is the software you or your team is building throw-away?

Really, the question that should be asked is a bit more complex, and the answer arrived at is one that should be shared with the team openly and candidly, and it should serve as guidance to many of the decisions made throughout.

Many of the very talented and skilled software development professionals I've worked with want to be part of a team creating a superior product, doing very high quality work. It instills a kind of artisanal pride, and there's an allure to being part of an effort to create a lasting piece of software development mastery. An enduring triumph, if you will.

I would argue that there is, in fact, a tendency for most teams undertaking the creation of a software product to veer toward overbuilding software in lieu of clear guidance as to how much quality and sophistication is enough. By the same token, I have also seen a great number of overzealous product managers push an agenda of supreme quality at the risk of project viability. And, of course, we've all seen the opposite, as well: rushing a project out the door, only to pay the price in spades later.

In my experience in solution and enterprise architect roles, some of the most important factors that have weighed in on the architecture and design decisions have been cost-benefit criteria. In short:

What are the costs to the business of delays of the system's roll-out?
What are the costs to the business of delays in making changes later?
How long will the system be in production, and how does that translate to maintenance costs over the product's life?
What are the impacts of errors in the system?
How likely is the technology to change in the near future that the product is built on, and will the company look to follow prevailing technology change cycles?
How tied to core functions of the business is the software?
What is the realistic likelihood of the system needing to be adapted to a new setting? (i.e. new country, new line of business, new language, corporate spin-off or merger, etc.)

Without answering these questions and more, you can never be completely certain that you're building the system in the right way. What is perhaps a little tougher to crack in this cost-vs-effort calculus is whether your current thoughts on any of these issues accurately reflect the future.

There are a lot of proponents of formal processes - formal requirements gathering, formal architecture, formal design, formal QA, and so on. Anyone who knows me and has worked with me knows that I believe a certain amount of all of these things should be consciously chosen based on the best-informed answers to the questions above. But, choosing the right amount is a delicate art much more than a science.

A friend recently asserted that I might not mesh well with a particular company we were discussing because that company didn't have a level of process rigor that he had come to associate with me. In truth, though, I think there's an appropriate amount of process that should be associated with each undertaking. It just happens that on recent engagements I've been part of undertakings that were to serve as core business function enablers, which meant we needed teams and processes that were more disciplined in nature, probably trending toward the median of the complexity range or perhaps just a little to the high side. I've also been on projects in the past that had well-understood short shelf lives, and these projects received much less process rigor, but it's always based on context and a conscious, calculated decision.

Focusing some of this discourse on the requirements, architecture and design pieces, the key reasons for performing these exercises in the first place in my opinion are:

Communication
Organization
Thinking through problems "on paper"
Project and corporate memory

Communication is paramount when dragging product visions and requirements out of people, when conveying design concepts, and when articulating plans. Formal communication is sometimes not necessary, though. If you're a lone developer working directly with the lone user of a very small, very simple system, it may suffice to capture requirements from meetings, log them somewhere so that the next poor sap who has to maintain the code can find them, and move on. If you're directly connected to the customer, with no middleman so to speak, then communication is a bit more natural and of course direct. There are obvious trade-offs down-stream to short-changing formal communication, which is a key issue some have with XP, Agile, etc., but the important question is not "if", but "how much is the right amount, both now and for the future".

Organization is vastly more important in cases of regulatory compliance, contractual obligations, in large and/or complex projects, or with a distributed workforce. Organization can be done by the team itself (think scrums, XP, etc., in the vein of self-orchestrating mechanisms), or can be done using heavy-weight processes with product lifecycle suites that can manage all artifacts related to the project in one place even with a distributed workforce. You would likely use a different organization approach to adding a page to your portal than you would to creating a multi-product, multi-vendor, multi-team, multi-million dollar health care system which lives would depend on and that would be subject to regulatory scrutiny.

All software projects involve R&D, thought-problems, uncharted territory, investigative research, and puzzle-solving. If people already knew how to build it, it probably would already be built and you wouldn't be reinventing the wheel (or one would hope - I know that's not always the case). But, how important is knowing why the team made a decision? How important is being able to track a series of decisions or actions? If the product will have a steady owner for years, maybe not terribly important. If it will pass through many people's hands, it may be critical. Tactical decisions made after release 1 of a product tend to be the force that erodes otherwise good architecture. Those decisions can be made for any number of reasons - laziness, time crunch, unfamiliarity, incompetence, you name it. Sometimes the documentation is there but nobody bothers to read it before making changes, so the formal documentation of why and how within a particular design would be ignored anyway. And, for some, formal modeling using UML or Visio's amalgam of elements is more constraining than simply drawing on a board. Knowing what the dynamics are today and in the future will help guide how much thought process should be captured and saved, and how much time and money to spend on the process of designing formally vs. designing on the backs of cocktail napkins. It'll happen one way or another, since it's an important part of the creative process for many, but the question is rather how much you care about formally representing it and making it consistent among projects and teams, and how you want to ensure it is leveraged in future actions.

And, finally, project memory. All of what I just mentioned speaks to this fourth point. How important is it to retain the "why" and "how" of your software systems? In some cases, it may not be that important. If you have a highly stable group of cross-trained professionals who are deeply familiar with the systems, it may show relatively little value to spend more than the minimal amount of time focusing on capturing formally the information and gyrations that went into creating them. This also assumes, of course, that the company will remain a static size and that your employees will never go elsewhere. However, the right answer here usually comes down to answers to the questions asked above. The importance of project memory goes up significantly in cases of outsourcing or partner-led initiatives, complex/large systems, systems that enable core business functions, reusable or composable functionality, in companies with high turn-over or frequent reliance on contractors, and with systems that are likely to enjoy a long life.

Understanding what the business is looking for out of the system, how much that's worth to them, and bringing that into balance with what the IT department needs in order to make a respectable return on the investment both in the near term and in the long run are tall orders to fill. But, to create synergy between the business that the technology serves, and the practitioners bringing it to life, this is an area that should be focused on with each new undertaking. When it's a whopper of a project, make sure everyone knows the level of specificity and attention to detail and historical record required. Likewise, when it's a one-off that will only be justifiably pursued if it can be brought to life with minimal expenditure, have a plan in place that is rational and has the minimum expectations in each area clearly spelled out in order to ensure that the business gets what it needs and the IT department can still make sense out of it toward the end of its life when maintenance or integration is required, as is almost always the case.

This ignores all of the factors that swirl around leveraging and feeding enterprise architecture, but for projects that are in-flight, hopefully this offers food for thought on how to right-size the project to meet everyone's needs, both short-term and long-term.

IT Leaders and the Lingering Need to Create

2007-09-28T09:11:00.001-05:00

I've had an interesting series of conversations over the past month or two that have followed a theme. I've talked, in some cases directly and in other cases in a round-about way, with a few different leaders on the subject of creating, and there so far has been unanimity on the subject, possibly at least in part due to the similarity of backgrounds of the leaders.

In all cases, we agreed that the rewards of leadership differ from the rewards of being in a creative role, such as a software developer, data analyst, application architect, etc. On leadership, the consensus among this group was that reward came in the form of seeing the people around you succeed in their personal and team objectives and grow as individuals. While being very rewarding to the types of leaders whose style is to focus on motivating, guiding, and nurturing their teams to reach their full potential and strive for excellence, it often doesn't yield tangible rewards that the leader can directly point to and say "I created that!" After all, if you're leading well, they created that - your role (at least in the leadership style I'm discussing here) is to have enabled and empowered, and to be proud and praiseful.

The other type of role, where one creates, has rewards that can be outwardly seen. When a piece of software emerges from your efforts as part of a team, there is something to point to and be proud of. Many of the IT leaders I know, especially some of the best, came from roles where they created things or were part of the team that created things - business analysts, project managers, architects, developers, data analysts, etc. In many cases for these leaders, there is a small void created when they are no longer creative within the IT context. The pride of creation and craftsmanship is lost, replaced with a different kind of pride, but one that doesn't necessarily fill the same need.

This can make for a tough transition for some IT leaders from someone who creates to someone who leads those who create. The creative drive that inspired them to get into IT in the first place doesn't just disappear. And, so, I think it's important to recognize the need, and have a way to continue to embrace and feed that need. Especially during a transition from creative genius to leadership phenom. For some, when a dissonance occurs after reaching a career goal of a leadership position after working years in the trenches, this creative outlet is critical in the effort to resist sliding back into the familiar role of creative talent with its extrinsic rewards.

If you're in IT leadership now after prior roles creating, do you have a creative outlet? Would you benefit from one? If you find yourself struggling with a transition from creating to leading, respect the need to create and provide yourself with a therapeutic outlet. Just because we stop doing something doesn't mean the desire ends with it.

My Bookshelf

2007-09-12T22:31:00.001-05:00

I was talking to a friend and colleague recently about books I've read that were influential. He commented that he most often reads technical books, but would like to explore some new areas of growth outside of the technical realm.

A few months ago, another friend and colleague began purchasing several non-technical books to improve his critical thinking skills, technology-agnostic design knowledge, and other facets of being an accomplished software engineer.

Yet another person I've been working with on a current engagement was talking to me recently about enjoying taking a break from reading technical books and focusing on such scintillating topics as time management. Clearly there's a common thread here.

In my experience, a lot of the IT professionals I've worked with get to a particular point in their technical growth where things just start to look a lot the same. New technologies resemble old technologies with prettier marketing; new methodologies look like recycled processes of old, just renamed and spiffed up for modern times.

The rate of churn is high in IT right now, with new platforms and APIs and buzzwords rolling out at a frantic pace. But, frankly, what we do in IT today isn't that much different from what we did 10 or 20 years ago. While technology evolves at a rapid pace, or so it seems from the consumer's perspective, the techniques and disciplines and even underlying technologies themselves honestly don't change that quickly.

I think practitioners get fatigued from the churn. Keeping up with a new technology stack from Microsoft every 18 months is exhausting, and there are plenty of articles out there to support that claim, so it's not just me! Eventually, I think these same practitioners begin to look for lasting self-improvement. Learning a technology has a half-life of a few years, as that technology will certainly be phased out soon enough and your investment in learning it will turn quickly into a decreasing-value asset as soon as the technology's replacement has been named.

I think this is at least a portion of what is behind, even subconsciously, the quest for some lasting knowledge and self-improvement. There is a great deal of wisdom literature that anyone can pick up and grow from in a lasting way, or at least in a way that has a longer half-life than "Learn ASP.NET 2.0 in 24 Hours". You just have to be willing to take a step back from the milieu of technology churn long enough to focus on something that transcends technology du jour.

To that end, here is a sampling from my bookshelf.

Non-technical books I've read and recommend:

First Things First - Covey, Merrill, Merrill
Built to Last - Collins, Porras
Leadership and Self-Deception - The Arbinger Institute
First, Break All the Rules: What the World's Greatest Managers Do Differently - Buckingham, Coffman
The E-Myth Revisited - Gerber
Danger in the Comfort Zone - Bardwick
Zen and the Art of Motorcycle Maintenance - Pirsig
Man's Search for Meaning - Frankl
The Mythical Man-Month - Brooks (well, not exactly technical, but this one might be questionable on this list; still, it's my list, so here it is)
Successories Great Little Book on Effective Leadership - Tracy (OK, I expect to catch some flak on this one, but there are some good quotes and one-line reminders mixed in with the cliches in here)
The Art of War - Sun Tzu
Tao Te Ching - Lao Tzu

Books I'm reading, read most of and need to go back and finish, or that are on my bookshelf waiting to be read:

Enterprise Architecture as Strategy - Ross, Weill, Robertson
Six Disciplines for Excellence - Harpst
Executive Intelligence - Menkes
Blue Ocean Strategy - Kim, Mauborgne
Every Mistake in the Book - Lennon

Have some books of your own that you think I should add to the list? Let me know, I welcome suggestions.

Understanding the Business - Part 2

2007-08-13T00:14:00.000-05:00

There are a lot of buzzwords in this industry of ours. I say words, but let's face it: IT people love acronyms like Dr. Phil loves quaint country colloquialisms. So, perhaps it's more accurate to say that IT people love buzzletters (though it doesn't exactly roll off the tongue, I know).

One of the big ones that I've worked with in my career is EA (Enterprise Architecture for the non-hip). For years EA has been yoked with the burden of fixing the woes of the modern IT shop supporting brick-and-mortar businesses - a way to harmonize and homogenize, a way to keep the flies out of the technology ointment. Has EA worked where you are? If your results are like mine, it's been a mixed bag.

Most people look at EA as a technology solution to a technology problem. I'm not the first to say this, but let me reiterate what a lot of very smart folks have said already: EA isn't a technology solution to a technology problem, it's an enterprise solution to a communication problem.

Most companies I've seen want to apply EA solely within the IT department to ensure quality in the software that go into the production environment (aka "build the thing right"). And, it's true, architecture is a facet of quality assurance as it can provide a lot of inputs and constraints to ensure that the products built or purchased are built right. I don't want to discount architecture's importance in building the thing right.

But, the word Enterprise doesn't just imply something, it states the obvious. EA won't live up to its potential unless the entire enterprise is involved. What's more, architecture isn't just a technical term, but I think that's actually the root of the problem: people assume architecture to be a technical discipline within the domain of technical work. Yet, the business is just as much a part of Enterprise Architecture as the IT department, each with different but connected responsibilities.

The reason EA fails is because the enterprise architects - those poor folks who are trying their best to make the technology serve the future of the enterprise - have very little true, accurate insight into the way the business works and the future direction that things are heading. There are some who have spent so long with the company that they know it as well as the people doing the work in the business, but those people are rare, and eventually they retire or move on. In short, most architects can ensure that we're building the thing right, but most lack anything deeper than surface knowledge into the business, the very knowledge that would ensure that we're "building the right thing", which is the other side of EA coin.

There are a lot of processes to make sure that we deliver good software products to the users on a per-project basis (despite the gross dearth of adherents to such processes). But, what about EA processes? Well, not too many, actually, at least not holistically speaking.

In pieces, we have EA covered, I think. There are a whole slew of buzzwords and acronyms that cover the gamut of what we need to do for good EA: knowledge management (KM), business process management (BPM), business process re-engineering (BPR), project management office (PMO), project portfolio management (PPM), business architecture, change control board, project review board, vision statements, project charters, governance, etc.

Let's pause for a moment. It would be great if EA were as easy as picking from the buzzword buffet the things that satisfied your appetite for closer alignment between IT and the business in a way that resulted in quicker results, better probability of the solution meeting the needs, the solutions being of a high quality and in harmony with the other solutions they interact with, all without spending a fortune and dedicating an army to managing it all. But it isn't.

If it were, I bet more companies would be touting how great their IT departments are at strengthening and extending their business models rather than (justifiably) complaining about how out-of-sync the IT department is with the business, how poor the quality of the results are, and how long it takes to get anything done. No, what modern enterprises with modern IT - which is to say technology woven into the day-to-day workings of the business - demands is an all-encompassing enterprise solution that begins with the C-level executives and permeates every part of the business.

What is called for is not just for technology to be woven into the business, but also a way for the business to be woven into IT. I'm not going to claim to have the answer on how to do this for every company out there. You may find some inspiration from sources like ZIFA and EUP, but I believe the starting point is something that looks comprehensively at the whole organization, empowers the business to own their business process information and strategic direction but holds them accountable for sharing and updating it proactively and consistently. It needs to create synergy between the business departments so that the left hand knows what the right hand is doing, and create ways for IT to tap into that information as early as possible and in a regular fashion in order to keep the ear to the tracks, so to speak.

I don't think there will be a one-size-fits-all answer to this new challenge. But, it is just that for those organizations whom EA would benefit: a challenge for IT leaders to spend more of their energy building a partnership with the business at the executive level in order to create support throughout the enterprise for EA from all angles and elevations. Then, to help shepherd and codify a process that can serve the entire enterprise, not just in building the right thing and building the thing right, but also in creating a foundation of understanding and communication that will lead to more productive and proactive collaboration.

Solving for X - Reducing the Complexity Within

2007-07-30T15:14:00.000-05:00

One of the tenets of good software architecture and design is the notion of minimal internal complexity (as opposed to external complexity). External complexity is the complexity of the problem itself, a difficult subject by nature - some things we do in the workplace are just simply complex and there's no way to simplify them beyond a certain point. Internal complexity is that which we introduce.

Some might call it "swatting a fly with a sledgehammer." We've all been guilty of it at some point or another. It just happens; we think we have a clear understanding of what solution a problem calls for, but instead of doing just the right amount, we overdo it. We provide a complex answer to a simple problem.

It's especially a danger in technology. For those of us working in IT as a supporting arm within a traditional business, we deal with a lot of external complexity in that we don't ever seem to fully understand the business, always finding ourselves dragged around by the tail just a half-step behind the change happening within the business, always playing catch-up to try to understand the new model and what the impact will be, always trying to better internalize how the business operates so we can be a better partner. For the most part, that external complexity will always be there to some extent.

And, for those of us working either directly with technology or within a pure technology-driven company, the external complexity comes directly from the work itself. Technology is a complex, ever-evolving landscape that no one can ever fully master. The best you can hope to accomplish is to be either really good at something that evolves very slowly (mainframe developers come to mind) and eventually fade into obsolescence (perhaps not the best career move); or, become really good at knowing how to adapt to and minimize the impact of that ever-changing external complexity. The really good technology people who stay abreast of changing technologies and who seem to move effortlessly from old to new tech as the landscape evolves have mastered just this art.

But, there's a more insidious danger in the technology world that stems from the internal complexity that we add to an already complex field. Taking it as a given that we are already tackling challenges of external complexity, it would seem to behoove us to simplify as many other areas as we possibly can. I liken this to an algebra problem where the student is asked to solve for x.

In an algebra problem, one often has a combination of variables and constants combined into expressions within an equation. Take an equation like this (my examples and definitions come from here):

7x - 2 = 8 + 2x

The steps for solving algebraic equations look like this:

Combine like terms
Isolate the terms that contain the variable you wish to solve for
Isolate the variable you wish to solve for
Substitute your answer into the original equation and check that it works.

Not too tough for an equation like what's listed above. But, what about something like this (I made this up, the aforementioned site isn't to blame for this one):

(ax/wq) - p * r = u²/(zc/kl)

Suddenly the equation is far more complex, and there are no constants, just variables. You might be able to isolate the variable you wish to solve for, let's say x in this case, but unless someone gives you the values that the variables represent, you won't be able to come up with a number that x equals.

Allow me a new but related tangent for a moment. My wife gave me a gift when we were younger: a paperweight. In the spirit of full disclosure, I should confess that I've never understood paperweights. I've never had paper that required weighing down while in the confines of an office. I guess I just don't work in drafty places. But, this paperweight has a quote from Francis Bacon that is always on the forefront of my mind: "Constancy is the foundation of virtues."

Now, not only do I think paperweights are dumb, but I thought that quote was dumb, or at least vague to the point of my dismissing it. Quaint? Maybe. Brilliant insight to life and the world around me? Not as far as I could tell. I politely thanked my wife for the thoughtful gift, and then... weighed down some papers with it. Splendid! Those papers went nowhere, so the paperweight was deemed a successful addition to my desk.

Years later, though, the simple brilliance of this quote struck me like a lightning bolt: It is the certainties in our lives, the constants, that enable us to tackle the variables. Now, that's what it means to me, and as with most quotes you lack the context, so maybe it means something altogether different; but, what's important (to me) is that it carries meaning now that resonates with me in a profound way. Those steady, bedrock aspects of our inner selves, as well as our outer world around us, are the things that give us a firm footing from which to strive to achieve something just beyond our ready grasp.

I should take a moment to mention that my wife is the most brilliant gift-giver I've ever known. She somehow taps into a person's inner self and finds something that even they might not know they need or want, something that adds to their life, not just to their collection of useless knickknacks. So, my appreciation for the paperweight has grown since it was originally given, and over the years my awe at my wife's gift-giving genius, among her many other inspiring qualities, has deepened. When I think about the constants in my life that have helped me to grow and achieve, she's at the top of the list.

As I've been confronted by ever-increasing external complexity in the workplace, I have seen an increase in the internal complexity introduced as a foil to the external complexity that well-meaning people are trying to deal with. But, as you can imagine, internal complexity doesn't quell external complexity; it amplifies it!

If your organization reminds you of the second, more complex algebra equation more than the first, what does that tell you? If you are in a complex environment that lacks constants, does that environment produce quality results in a timely fashion? Are people inspired, empowered, fulfilled and rewarded by the work they do? Or is it an environment that creates churn, frustration, animosity, political games, communication disconnects, information silos, sub par work, and frustrated partners and clients? I've seen several environments where smart people couldn't even figure out where to begin attacking a problem, because there were too many other variables that weren't yet settled: shifting org structure, undefined communication pathways, unclear/absent/confusing/onerous processes, unclearly defined responsibilities, turf wars, you name it.

If your people are struggling to be effective in accordance with the goals and principles that matter most in your organization, I urge you to take a good hard look at whether their equation has more variables than constants. Find ways to create the stability and firm footing that will serve as the foundation of the virtues you want your organization to embody and the support for solving the variables that matter most.

One-on-One Leadership

2007-07-17T21:09:00.001-05:00

For all the things leadership has been said to be, the one thing that is at the top of my list is that it is personal. Simply pointing toward the "right" path doesn't mean someone will walk it. And, even if they do, that doesn't mean that you have provided leadership - it could just be that the only options are to walk the path or find another job.

Any person in a position of power can dictate the direction that his team will take. This is vested authority - by virtue of the position, that person has the power to initiate action unilaterally.

What I want to talk about in this post is earned authority, the kind that one person might give another person of their own free will, regardless of rank. In other words, a person would follow this kind of leader regardless of the title or vested authority she holds. This leader clearly offers something, some insight, some vision, some clarity, something special that inspires an individual to voluntarily buy in to much of what she's saying and follow her through the fire, even if questions arise along the way. (I should mention that the notion of vested and earned authority is something I have read, but I can't recall where. Please post a comment if you've seen it so that I can attribute it here.)

This kind of earned authority is one based on trust that can only be built through personal exchanges, slowly, over time. It's a relationship. It's personal. I'll say it again, it's foundation is trust, which is best built one-on-one, through kept promises, through constancy and consistency, by giving up control, and by giving trust even before receiving it. This type of leader doesn't rule by fealty. Rather, this type of leader leads by following.

That is to say, this type of leader takes time to imbue her team, one by one, with the values she holds most dear, and then trusts that her team will faithfully execute on whatever tasks arise with those shared values as their guide. The tasks will change over time, especially in IT; the values of the kind of leader I'm talking about will not. The leader whose team is best equipped to be her eyes and ears and to take action with clarity of values guiding the way will have enabled her team to lead for her.

As an IT leader, you'll likely never be able to be the expert in all technology areas that you're leading. Chances are good, in fact, that you're not an expert in any of them. But, the values that matter transcend a given technology of the day. And, by creating that one-on-one relationship, by building that trust, by sharing those values, by letting their input and feedback guide your leadership as much as your leadership guides their actions, over time your team will be the leaders. And upon their successes, they will rightly and proudly say "we did it all by ourselves!" And you will be the first to cheer their successes, for they will have led themselves.

Spend a little time every week making sure that you communicate what matters most to the people who matter most on your team. If you find yourself dictating to them, stop; if you have to dictate to your team, you either have the wrong people on your team or you're not doing an effective job of communicating. But, if you find yourself painting in broad strokes, letting your team fill in the painting with the fine strokes, the strokes in the painting that matter most, all while resulting in the painting you imagined or better, then you clearly have lessons of one-on-one leadership to teach. Teach those lessons to someone on your team and empower the next generation of one-on-one leaders.

25 Champion CIOs; A Champion Small Business

2007-07-11T13:40:00.001-05:00

Seems like more often than not, articles on IT leaders are just fluff pieces. While still a bit on the fluff side, I did enjoy this article on 25 Champion CIOs (registration required) in the mid-market on SearchCIO.com. There are some interesting strategies being employed by innovative IT leaders in good-sized businesses with small IT staffs to creatively push value out to the business, cut costs, improve business-IT relationships, and strengthen IT teams. Congrats to the winners - I suspect the honor is well-deserved.

Also deserving congratulations is Steve McConnell's company, Construx. I just posted recently my admiration for his work and his company's approach to professional development, and now here is Construx making the headlines as the best small company to work for in Washington state. This link is to part 1 of what is supposed to be a 3-part series.

These kinds of insights can be valuable for helping us break out of a rut of isolated thinking and gain insight into other successful paths that we might not come up with on our own. Humans are great mimics, and I think there are some great ideas to adopt and adapt in the links above. See if any of them would apply to your organization.

An Inquiry Into Values

2007-07-06T09:07:00.001-05:00

I received a comment tonight from a fellow consultant regarding my obvious lack of Zen references for a site with Zen in the title. I thought about it a bit after the conversation and decided that he had a valid point.

The title of the blog, which by the way was about the fifth title that I tried out before settling on Zen and the Art of IT Leadership, was inspired by the fantastic book Zen and the Art of Motorcycle Maintenance, by Robert M. Pirsig. Strictly speaking, it's not so much a book about either Zen or motorcycle maintenance. In fact, that's given away by the subtitle, "An Inquiry Into Values."

Among other subjects, the book spends a fair amount of time on the subject of quality. What is quality, really? At the heart of this question is the dichotomy of understanding, a bifurcation that results in Pirsig breaking our modes of understanding into two: classical understanding and romantic understanding.

Now, the author spends an entire book delving into these subjects (and more), so I can't possibly do them justice here. But, it will suffice to say that classical understanding is more interested in function, or the underlying design and workings of something; on the other hand, romantic understanding is concerned more with form, or rather more about the emotional appeal of the appearance of something, more an appreciation of the surface.

One with a romantic mind may find a Ferrari to be extraordinarily appealing by virtue of its sinuous lines and swooping shape, its exotic sound, perhaps even the way the cockpit envelopes the driver.

Meanwhile, the classical mind will find endless interest in the engineering of the same Ferrari, the details of the suspension design, the way the F1-style paddle shifters operate, the computer-controlled drive-by-wire system and its interactions with the traction-control system and the electronic control unit governing the power delivery.

Both of these kinds of understanding find appreciation in the same car. In some cases, they are almost the same, noting that form sometimes follows function, as witnessed when observing the striking shapes that result in a car's nose after many rounds of refinement in the wind tunnel, resulting in a visage that is truly shaped by the wind.

So, what does this have to do with Zen or IT leadership? Well, it doesn't have much to do with Zen, unless you happen to have a chance to drive one (at which point I think you could probably find a Zen-like state after a few miles). But, I think it actually has a lot to do with IT leadership.

As an IT leader, it helps to be able to work with both modes of thinking. Classical thinkers are often the ones delivering the IT systems that empower your business to reach new heights. Romantic thinkers are the ones coming up with all the new reasons for needing new software, shaping the business direction, charting new courses, and imagining what could be. Romantic thinkers often can envision what they want their world to look like, and don't much care about the details of making it happen. Classical thinkers often want to get an idea of what needs to be done and then become inspired by the nuts and bolts of how to make the implementation a work of art in its own way, as elegance in design and construction.

Without someone to embrace and attend to all the details, there would be some pretty lousy software out there. How many spreadsheets, Access apps, and little VB projects have you inherited in your career that were built by romantic thinkers just to get a job done, without concern for the quality of the construction? If you're like me, you've seen more than you'd care to. And, how many applications have you used that you just knew were built entirely by programmers, or in our current vernacular, classical thinkers, without much attention to the visual appeal of the user interface?

In truth, most people have a healthy blend of both classical and romantic understanding, even if they do have a leaning. I know of plenty of programmers, no doubt mostly classical thinkers, who find Ferraris to be great looking cars. Likewise, I know some business executives, whom I think we can agree are often more romantic than classical thinkers, who are intrigued by the details of a car's design and function under the sheet metal.

But, as an IT leader, you have the unique opportunity and responsibility to balance both. You must embrace classical thinking and inspire classical minds to do their best work in creating well-designed and well-functioning parts that work in harmony below the sheet metal. At the same time, your duty to the business is to ensure that the form that this elegant engineering feat is wrapped in represents the business leaders' romantic vision of the future. (Oh, and let's not forget your own visions of how your department should function, and all the underlying details that enable that. But, we'll set that aside for this post for the sake of simplicity.)

Said another way, you want neither a Ferrari wrapped in a Yugo body, nor a Yugo wrapped in a Ferrari body. If the business just asked for a Yugo, make sure your IT department knows it's building a Yugo. Same goes for the Ferrari. And, if the business thinks it's asking for a Yugo, but just happens to have optioned its request up to Ferrari levels, make sure the channels are open for communicating what it takes to build a Ferrari to ensure that the price tag and capabilities match the picture.

When you can communicate the romantic understanding to the classical-minded, and the classical understanding to the romantic-minded, all while still inspiring both to thrive, you will ensure quality is delivered to match both parties' satisfaction.

(If you crave more meaningful, substantive Zen reading material than the drivel found here, have a look for starters at the Noble Eightfold Path, which holds some teachings related to this already-too-long post, which I will lengthen no more.)

Understanding the Business - Part 1

2007-07-06T09:06:00.000-05:00

One of the great things about being in IT is learning about different types of businesses. As a consultant, I have had the privilege of being exposed to at least a couple dozen different business worlds, ranging from concrete forms to entertainment, "Big 5" (back when there were the Big 5) to startup, bio-science to telecom. It's really been something I've cherished, and feel as though I've somehow found a loophole in the system to be able to experience so many business models and to have worked alongside leaders in areas that I knew little about before stepping through the door.

Despite the different business areas, the challenges are not unique. Often the core problem is one of matching IT's work with the business's objectives, ensuring that the money spent on IT aligns well with the strategic vision of the business at large and that the detailed IT work accurately reflects the real processes that the business wishes to utilize.

Rarely are IT employees experts in the field within which their company operates. And yet, those IT employees need to know enough to be able to execute on the business model being implemented, refined, and/or automated through technology. As a result, IT employees over time become expert in the way the business works, at least to a point, within a certain scope.

The challenge usually isn't getting the technology in place. Software development, software integration, software deployment - these are all areas that, in a reasonably mature IT shop, are generally not the foremost concern. That's not to say that they lack challenges and don't need good leadership direction, but with reasonable process and tools support and good people, they can be of lesser concern.

Instead, the real challenge at the root of it all is in understanding the business. Really understanding the business. Why is this such a challenge? Can't we just ask the business how the business works? In my experience there is often a disconnect between what leaders think is happening and what is really being performed where the rubber meets the road.

This creates a dangerous impedance mismatch - sometimes business leadership is trying to solve problems that are perceived rather than real. Sometimes the business leadership is aiming to automate something that can't easily be automated. And, at times, you end up with the worst of all worlds: all of the aforementioned, plus differing takes between peer executives on how to best improve those processes that aren't well-understood in the first place. How did we get here, and how do we get past this spot?

The role IT often gets put in is one of arbitrator: figure out how to make sense of all the different processes that exist, figure out how to make new ones that are tech-enabled and are better than before, and ride herd on merging all of the different opinions into a unified whole; then, get buy-in and sign-off from the executives, who may think that the whole thing is way off base upon review simply due to a difference in perspective. Think about this for a minute, though: you're asking someone such as a business analyst to make, in some cases, what should be business and executive decisions, without the benefit of full information and insight into how all the moving parts of the business operate and inter-operate. To compound this, try doing it with a new analyst who is a consultant just getting acclimated to your business model and particular business instance. A tall order, and fraught with potential for failure.

But, what if your business made it a priority to maintain the way they do their business? What if that information had to be updated periodically, and was to be reviewed by the executives in charge and the departments who would be affected? If you could point your IT staff to a "book" (OK, something electronic, but you get the idea) that described how your business runs, would that offer benefit? Could you justify the expense of keeping this information up to date? Could you justify not doing so?

The rebuttal that I have gotten in the past to suggesting the business manage their processes actively has been that the business needed to be agile and respond quickly to opportunities. To this I say that some businesses do fall into this category and some don't, but in most cases, wouldn't that change be easier if you already had the rest of your processes nailed down, and only had to review what exists to see what would be impacted and change those accordingly? And, if you could ensure that your IT systems speak directly to your business processes or were in fact integrated into their descriptions, you would have a direct correspondence between business change and IT change. This, as opposed to IT driving business change from the "bottom up" or through constraints in the technology.

In working in the past for a company that does studies in support of pharmaceutical companies, among other services and products that they offer, I found a place where business processes were tended to just as much as customer relationships. The reason for this is to ensure compliance, as governed by bodies such as the FDA and the corresponding Good Laboratory Practices guidance. This company has standard operating procedures (SOPs) that can be referenced by anyone at any time, training requirements to ensure employees know the procedures, and auditing to ensure that the procedures are adhered to. For many businesses this overhead is overkill to some extent, of course, but when lives are potentially at stake you're glad they exist.

I believe that somewhere between the seat-of-the-pants business processes that most companies employ and pass on verbally, and the rigid GLP-oriented model that ensures that our drugs are safe, there lies a healthy middle ground. IT is going through a value-up shift these days - IT must speak to business value, match up with strategic initiatives, and have ROI justification for proceeding. But, all too often we start with the software as the first step in the progression from business vision to final product. Instead, start with the business change, the impact to human workflow, the changes in human processes, and the vision for how it should all look in the end. Then integrate technology as a partner to getting there.

There are many business process management initiatives going on out there right now, and time will tell if this new BPM fad will catch on. The more companies who treat their business processes as assets to be maintained and improved over time, and the more respect given to the impact and role of technology in them, the fewer projects we'll see fail due to incomplete vision and scope, lack of executive and management involvement, and incorrect responsibility ownership for business process transformation.

If you're nowhere close to being able to say you have SOPs, how do you get from ground zero to business process management? There are a lot of business process management pundits and consultants out there, and there may be help to be found among them. But, if you want to tackle it yourself from scratch, I say start with the basics:

Evaluate first if capturing business processes will add value. This may not be a perfect fit for every type of organization. Some companies really do require flexibility to make changes at a breakneck pace (startups for example). If it's a poor fit, stop reading now and direct your energies elsewhere. But, really think long and hard about the true pace of change in your organization before answering.
If you have business analysts, let them take the lead by giving them ample training in your business and extensive access to the experts in the business processes. They should document their findings in a centralized, consistently organized location following guidelines and templates, using the business's language with no reference to techno-speak unless referring to systems used to perform business tasks, and have those findings verified by the experts in the business.
The process information should be available to all relevant business units, all interested executives, and anyone else frankly who is interested and who should be allowed access access. (If you have a corporate portal, this might be a good use for it.)
Make certain that key executives or line of business managers are in the sign-off process, but also ensure that the people doing the processes have say in the review and sign-off process as well.
Make it a priority to review and update the material regularly as part of a routine, scheduled process, and make it part of your process to review them when something changes. (And, by the way, you can also use this material to train new employees, yielding more rapid time-to-productivity and consistency in the work performed by the new hires or transfer.)
Start with your business-critical areas first, and then work out in descending priority order. Don't tackle it all at once.
If you don't have enough business analyst horsepower to document the processes, try to get your business users to document them (this is how it's done in SOPs). Make sure there's a template to follow to ensure consistency, and ensure the right people are in line to review for content as well as style and organization.
Lobby to ensure that, organizationally, there is emphasis on working on your business, not just in your business. Carve out time on a regularly scheduled basis and make it part of your culture.
If all else fails, just ensure that you have time in your project schedules to capture business processes as you go and build up your business process library incrementally, one project at a time, making sure to begin with the end in mind from an organization and management standpoint. Business processes are like anything else: they will grow weeds if they aren't intentionally and regularly maintained.

Now, what do you do with all these business processes once you have them? More on this in Part 2.

KISS Method in IT

2007-07-04T13:20:00.001-05:00

I touched briefly on Steve McConnell's company, Construx, in the previous post with respect to professional development, but I didn't really say much about Steve McConnell. To put it plainly, there isn't another person whose writing has influenced my work more than his.

I think there are a lot of things that most IT shops can take away from the great material found at the web site of Steve McConnell's company. The entire CxOne process is available to anyone who is interested, and their CxOne Basic offers a lot of great starting points to establishing your own process, for free (with registration). There are few people in the industry who have contributed as much to the craft and science of software engineering as McConnell. To see what I mean, just pick up one of his books (Rapid Development would be a good one to start with for many IT leaders, in my opinion).

Truthfully, his lessons are often very simple, keying in on the foremost advice I have for all IT departments: just start by doing the basics very well, give your team lots of supporting material (templates, checklists, etc.) that help them do it right every time, and breed consistency and constancy in everything you do. The less your teams focus on how to do their jobs (how to write and manage requirements, do design, conduct code reviews, etc.), the more they can focus on what they should be delivering for the users. Software projects are complex - do everything you can to free up brain cycles to focus on the important stuff instead of the mechanics of doing. (If a concert pianist had to locate each key before every note, well, the concerts would be pretty poor I suspect.)

As a side effect, the more consistency in how your teams work, the more comfortable your users and subject matter experts become with the process of giving guidance and requirements. The more comfortable they become, the higher the quality of information that they provide and the better prepared they typically are for participating in the process.

There's a natural tendency to want to jump straight to CMM 3 and be good at everything right away. But, it's been my experience that you can't skip ahead as a department. You have to build slowly, spending the time working on the business of IT a fair amount rather than always just working in the business of IT. Someone, or some people, within the department must own the responsibility of improving how IT is done, year over year, while making sure to preserve and improve what is already established.

It's a slow road, yes, but if your department builds a stable foundation of fundamentals first, with attention given to doing the basics well, integrating the team's efforts, reducing some of the complexity that comes from each project team working differently, and communicating effectively within the department and outside of the department, in time that slow and steady improvement results in world-class capabilities that show good stewardship of people's time and company dollars.

But, you can't skip steps; start small, build on those small successes, and enhance the capabilities of your people and your processes over time until you've arrived at the goals you've set for your organization. If you're looking for some guidance on how to do it, look no further than Steve McConnell's books and his Construx website. And, keep it simple.

Professional Development for IT Employees

2007-07-04T00:40:00.000-05:00

One area that I get asked about on consulting engagements routinely is how best to establish professional development programs that work. I have material that I've developed over time to help with this, but much of it is influenced by the very good material at Construx. Specifically, I would point out that their Professional Development material is very well thought-out and well-rounded. I think there are areas of it that simply can't be applied in some organizations, whether due to long-established HR rules and org structure, or due to there being a point of diminishing return for some organizations that lies somewhere below the lofty heights of individual and organizational development that are proposed at Construx. Still, I think every IT shop can learn a lot from what they have to say on the subject of professional development and career ladders.

SOA in the Enterprise

2007-07-02T16:14:00.000-05:00

Overview

SOA, or Service Oriented Architecture, has been all the rage for a few years now. Every pundit, tools vendor, architecture guru, and street corner hotdog vendor has cited the myriad ways that SOA can make your organization leaner, more agile, and look 20 pounds thinner. If you're a savvy IT veteran, you know to view these promises with a healthy level of skepticism.

How much of SOA is truly transformative and valuable, and how much is just hype manufactured to sell products and services? I'll give you my take based on my experience.

The Backstory

SOA is a pretty generic term, with myriad definitions. I won't try to nail down a definition in this post. Instead, visit our friend Wikipedia for a pretty good treatment on the subject. It should suffice to say, for our purposes, that SOA is a style of architecture that composes shared, reusable functionality into business processes at a macro level, rather than decomposing to the class level as object-oriented design would.

How these services are implemented is subject for much discussion, as there are a number of technologies with which to implement a given service - as XML web services, as remote procedure calls (RPC), using SOAP, using REST, etc. For now, we'll just go with the much touted Four Tenets of Service Orientation:

Boundaries are explicit (communication is done via messages across the wire)

Services are autonomous (a service provides functionality in isolation - its capabilities aren't dependent on other services, and a service is allowed to change over time without worrying about impacting another service, at least in theory)

Services share schemas and contracts, not classes and types (since everything is message-based, all that a service shares with a client is the types that can be passed in and returned, which are for our intents XML-based)

Compatibility is policy-based (policies define how clients and services may interact, as well as how one service may interact with another, essentially defining the ground rules for whether a service can be used in a given setting)

So what does all that mean? Each service is its own mini-program, a little program island if you will, and each one defines specific ways that outsiders can communicate with it. If it chooses to change those communication contracts, that's its choice, and others will have to react accordingly. If it chooses to change what functionality changes under the covers, it has the license to do so autonomously at its choosing.

The Value Proposition

I'm going to narrow this down to SOA in the enterprise. Where does SOA provide the most benefit in typical companies that are brick and mortar and are trying to leverage technology to give better core IT services and reduce cost of ownership, time to market, and the impact of change?

The areas where SOA is most often cited as being a help include:

Integrating two or more disparate systems

Institutionalizing and sharing core business processes and rules of an organization

Exposing functionality from an existing system to the enterprise or external partners

The hype around SOA has told us that it will let us create loosely coupled systems that can be composed (combined) together to create more complex functionality, offers easier and lower-cost maintenance, all while leveraging standards-based intercommunication.

That actually sounds pretty great, doesn't it? So, why am I even writing about this if it's so great? Good question.

My Take

There are a few issues here: one is syntactic coupling vs. semantic coupling; another is performance. There are more, but for the purpose of this post I'll stick with just these.

First, let's address performance. The bottom line is this: you pay a performance penalty using SOA. There's a lot going on to make SOA possible: converting data to and from XML; opening network connections and feeding requests and receiving responses; dealing with other network traffic; and, sharing services with others, which could result in slow processing with popular services that get a lot of concurrent use. As a general rule, if you have something that needs to perform extremely quickly (near-realtime, like we're accustomed to seeing in-memory operations perform), think twice about using SOA to solve that particular challenge or risk disappointing your users.

Syntactic coupling is another way of saying that to talk to a system written in one language, you need to use the same language. XML-based SOA solves this problem - any system that meets the policy requirements and can talk XML can probably consume a web service. And, any system written in a language that can be used to expose XML-based services is a candidate for being opened up as a service (again, I'm focuing on XML-based services). By using standards-based approaches, SOA breaks down the syntax barriers between non-compatible systems by providing that common language for each to use. This has been the big advance of SOA - giving all of these disparate and incompatible systems a single language that enables them to be able to talk to one another. It's safe to say at this point that we have pretty well solved the syntactic coupling problem by simply utilizing XML-based services (as opposed to, say, RPC).

Semantic coupling is the problem that SOA doesn't solve, and in fact, I'd say it has made this worse because of the hype about SOA making everything loosely coupled. What is semantic coupling?

Semantic coupling refers to the behavioral dependencies of one service on another. In other words, one service or client is relying on another service to provide a particular bit of functionality in order for everything to work properly. This is a lot like an old C program - one function is called to perform a particular task, and then it may call other functions to perform more tasks, but it's very procedural, and each function, or service method, can be chained one after another into a deeply nested set of calls that the original caller has no idea became so involved (and, in theory, hopefully doesn't care).

Why is this an issue? It goes back to the issues of boundary and autonomy. Because each service may change independently, and because there are explicit boundaries (each service is a black box), consumers of that service have only the service definition to go on for what it will provide. If that service changes, and most services do over their lifetime, the risk is that some or all of these dependent consumers may break, and they won't know they're about to break until it happens because of our beloved autonomy. Or, worse still, nothing breaks overtly, but the functionality has changed in a way that breaks the application subtly, creating incorrect results without our realizing it until a user complains (or, worse yet, until an auditor complains).

How big of an issue is this, really? Well, here's the rub: it's not as big an issue as you might think, if you have a skilled and experienced staff (especially where services are concerned), well-defined processes for your IT organization that help you manage change effectively at both the business end and the IT end, have sound testing practices to ensure all affected paths are tested before deployment, and, ideally, have a sound versioning strategy for your services.

What if your IT organization doesn't fit those criteria? Well, services may still make sense, but I would caution you to dip a toe in carefully at first. Here is my guidance to IT leaders considering adopting SOA in their IT organization:

Start small with a low-risk first attempt. If you have an existing system with functionality that another system needs access to, expose a little bit of that system's functionality, but just what is required to get the job done.

Create standards and processes around your SOA practice. Define how changes will be implemented and tested before deployment. Define when and how services are to be appropriately used. Most importantly, define a versioning strategy for your services to maintain backwards compatibility.

Have your architects or development leads for SOA read Rockford Lhotka's excellent post on semantic coupling and Gregor Hohpe's excellent article on event driven architecture.

Focus on functionality or capability sharing, not data sharing. Trying to manage a giant schema of classes-turned-XML is a tough entry into SOA. This goes back to keeping it simple and focusing on small bits of functionality initially. Sticking with passing messages and having services do real work, rather than just passing big XML data back and forth, will ensure you have the best results initially.

Make sure you have a very clear strategy on how to tap into the business's process and rules changes. These changes will drive a fair amount of your service changes, and will be a source of a good number of your breaking changes (including subtle, functionality-only breakage that doesn't overtly break at runtime). Managing change in the business and rolling those changes into technology is a subject for another post, but this is critical to ensuring that your services are serving your business well.

Model your services and service interactions right away, from the very beginning. If you can't point to each service available in your organization on a diagram, you will have a harder time managing the services over time and ensuring that they are being leveraged correctly. If you can't point to how services are composed, via a sequence diagrams for example, you will have a tough time knowing how changes will ripple.

Be very explicit in the service definitions about what a service will provide. Remember, it's a black box, but the consumers need to know what they're getting from calling that black box in order to know how to compose service calls correctly to produce a desired outcome. Will an order fulfillment service ensure that the order is picked, packed, and shipped, or just fulfill some part of that sequence and leave the rest to the caller to compose on its own using a different service for, say, shipping the products?

To be clear, tackling SOA is a big undertaking that typically yields best results to mature organizations in my experience. Those organizations that have mature system assets and sound processes tend to leverage SOA well, because they are organized and also because they are exposing existing functionality that has been tested and stabilized already and a need has been defined for exposing that to a wider audience.

Where I have seen IT organizations get tripped up is leading with SOA out of the gate, without a plan for successful implementation, and without going through the product and/or organization maturation first. Still, if you're the head of an IT department that is going through maturation pains today but still need SOA, follow the steps above and take it slow, applying SOA only where it fits the problem very well, and you can find success with SOA. Be prepared for some growing pains, and expect some additional cost and overhead in maintaining yet another technology stack beyond what you have today. But, when applied correctly, with the right expectations, and with the right resources and effort backing it, you should be able to avoid being another of the horror stories of SOA adoption that are starting to emerge in the "trough of disillusionment" following some unrealized promises of SOA.

.NET 3.0 - Why you care, but don't need to act

2007-06-29T09:35:00.000-05:00

Overview
In this first Tech Brief, I'm going to lead off with a post regarding the question that I received yesterday on .NET 3.0. What is it, really, and should we be using it (or even care about it) just yet? (I should note that a lot of my Tech Briefs will be focused on Microsoft technologies, primarily because that's what I know best and work with most regularly, but I will try to mix it up now and then.)

The Backstory
.NET 3.0 is what I would refer to as an transitional technology release from Microsoft. First of all, it's an important technology set because it is a critical underpinning to Windows Vista. Of primary concern is that it offers Windows Presentation Framework, or WPF, which offers some advancements in mainstream UI rendering technology. I won't call it revolutionary, but it's definitely a healthy evolution on the PC platform. More in a minute on WPF.

.NET 3.0 is available as a download for Windows XP as well. You can install .NET 3.0, then go out to the New York Times and download their very cool newsreader program written in .NET 3.0 and get a real taste of the power of WPF without loading Vista - for a quick example in the newsreader, just resize the reader and watch how the reader resizes all of the content dynamically. That alone is a big advance in UI technology for developers who will can now allow the underlying technology to take care of dynamic resizing (and a lot more).

That's just a quick sampling. Let's delve in further.

The Value Proposition
In addition to WPF, the other big technology additions in 3.0 are Windows Communication Foundation (WCF), Windows Workflow Foundation (WF, since WWF is sort of taken already), and CardSpace.

WPF - As I mentioned before, this is the new display technology from Microsoft that underpins Vista. Vista looks how it does because of what WPF offers. WPF will enable user interfaces to make a big leap forward in how they look and act, I predict, and Vista only shows the tip of the iceberg.

WCF - This is the foundation for the next generation of web services support. This technology is a big advance in the services space in that it allows a programmer to write a service once and expose it via multiple channels (HTTP XML web service for wide compatibility, binary over TCP for speed when using a .NET client, message queue for reliable asynchronous message delivery) just by changing configuration settings. Pretty cool stuff, and a pretty big deal.

WF - Workflow and business process technologies are big right now. Everyone wants to be able to manage processes in the enterprise easier. WF is Microsoft's latest answer to the workflow and process problems that enterprises everywhere are trying to solve. It differs from the workflow technology that is in BizTalk, but I won't go into that here. What you may want to be aware of, though, is that WF will be part of a future release of BizTalk, replacing the current workflow technology that is in BizTalk today. You may want to start asking Microsoft questions about future compatibility and what will be involved in upgrading to the next release if you have already heavily leveraged BizTalk's current model.

CardSpace - This is what I would call the redheaded stepchild technology in .NET 3.0. CardSpace is a client-side technology that allows users to manage one or more digital identities that can be shared with various providers of a technology service, such as your bank or an online store. These digital identities contain personal information, and act as both authentication and authorization mechanisms. CardSpace is Microsoft's implementation on top of an architecture called The Identity Metasystem, which is a broad initiative that isn't strictly a Microsoft undertaking (though I understand it was Microsoft's Identity Architect, Kim Cameron, who initiated it). This is an attempt to standardize the way in which we manage our identity information online, in a more secure fashion than we do today.

My Take
These four technologies are going to be huge in the Microsoft technology space. In the future. Right now, they deserve to be nothing more than blips on the radar for most enterprise IT shops.

The reason I say this is that the tools simply aren't mature enough yet to enable knowledge workers to fully leverage these new technologies, and adopting now could be a recipe for frustration. For WPF, there are finally some tools (Expression Blend, for instance) coming out to support it, and Microsoft is pushing a separation of design and code with their new offerings - splitting the designers off to use Expression and letting the developers continue to use VisualStudio.NET, with the designers making expressive and intuitive interfaces and then handing off the project to the programmers to rig up everything in the background to make it all work.

Great in theory, but the VS.NET add-ons to support WPF really aren't ready for prime time use by anyone but the most bleeding edge early-adopters. You can use the Expression Studio to do it all, and it appears to be a neat product, but unless you just really need to be an early adopter, I'd wait for the next release of VS.NET (codename Orcas) before jumping on the bandwagon.

WCF and WF are both very promising technologies, and they're both closest to being fully baked. The development support is pretty good in VS.NET via the add-ons, though there are still some hiccups and some rough edges once you get into them deeply. And, when it comes to deploying and managing the technologies, I think there are still going to be some shortcomings.

You can deploy WCF services on IIS, in a console app (please don't try this at home), or in a Windows Service (also, not the best approach, IMO). I think Microsoft has bigger things in mind for how to host WCF services, but at least you can host them through IIS, which would be fine. But, if you want better management and control of WCF-based services, I think waiting until later in the year to see what Microsoft has in store may be a good bet to hedge.

WF is a compelling technology, and is already in use behind the scenes in the workflow capabilities with the new SharePoint (MOSS 2007). It looks like it will be a much easier tool to use for workflow and process definition than the stuff that exists today in BizTalk. However, it's not terribly performant, so it may be best for long-running processes for now, and it seems in some ways like it was designed more for desktop app workflow and then they decided later on that it should be made to work in a multi-user environment (web sites). And, there are some things about the programming model that I'm not crazy about. I think this is another technology that will gain some polish in the upcoming .NET 3.5.

And, so, that is really the point. .NET 3.5 will be released with the next version of VS.NET, and will offer much better tools support for these promising technologies. If your enterprise can wait, hold off on adopting the technologies until you've spent some time looking at Orcas and evaluating whether things are evolving in the way you'd like to see them. The next version of VS.NET and BizTalk will bring tighter integration with WF, WCF, and WPF. I don't know too much yet about the future of CardSpace, but for most of the enterprises I work with, it's not a critical piece of the tech puzzle today.

Before you sink a ton of money into developing for .NET 3.0, consider waiting for .NET 3.5, where these technologies will likely have far better tools support and maybe a little more polish and cohesion.

Inaugural Post!

2007-06-29T09:06:00.000-05:00

I've been in technology leadership for over a decade now (11 years at the time of writing this), providing leadership and guidance on technology strategy, selection, implementation, construction, and stewardship to companies big and small. I live on the bleeding edge of technology, sensing trends, drawing from my experience to divine which ways the wind should blow, regardless of which way the prevailing trends point.

So you would think that I would have had a blog by now! It's the reason behind why I haven't that reflects my personal philosophy on technology, though: there must be a tangible benefit within the context before I advocate technology adoption. Technology can solve problems, but it's important to have identified a problem first, and then see where technology fits.

To wit: during the course of my past three years of consulting I have witnessed, along with everyone else I'm sure, the surge in the pace of technology advancements. I'm asked on a regular basis now about the latest technologies, methodologies, enterprise strategies, and so forth, often by the IT leaders I'm working with. It only makes sense, though, when you consider that the focus of IT leadership isn't always on what the latest and greatest technology is, but rather on leadership.

Many of my recent engagements have required IT leaders to lead transformative change in the organization in order to provide better IT service to the business (and this often is why I have a consulting engagement in the first place). But, in the course of leading their departments, there is often precious little time to gain valuable insight, i.e. more than just passing knowledge and buzzword awareness, of the key technologies of the day. And yet, it's this below-the-surface knowledge that is required to make sound IT strategy decisions.

So, back to my point about technology needing to provide tangible value. After recently fielding a new question from the IT leader that I work with currently, it finally sank in that it is time that I share what I know, the value that I have to offer, through my own blog. This is where I will post my insight and opinions on the trends and technologies as I see them through the filter of my experience, and where I will try to separate hype from substance. The goal will be to provide insights into technologies that are relevant to the modern IT leader, without having to read a lengthy technical book to get to the important details.

And, speaking of books, I've written quite enough for a blog with "Brief" in the title! I hope you will find the content here valuable.