Articles for November 2012

Sometimes You Pay the Fine

Date: November 28, 2012 Author: Jeff Comments: 1 Reply

No project should ever be considered without considering the cost of not doing it at all. This goes for both technical and non-technical projects.

I worked in the financial services industry for many years. Every few years I was approached by semi-hysterical business leaders who wanted to sponsor quick-and-dirty projects to satisfy some regulatory mandate. The only information they could supply was that it was a mandate and there could be fines for non-compliance.

When vetting any project, it is necessary to understand the cost and benefit of every option for satisfying the need. Quick-and-dirty is always an attempt to brush over the lack of benefit by assuming that the cost is absurdly low. While that may be true in the short run, it’s rarely true in the long run when all of the facets that were missed come to the surface as unexpected consequences of the quick-and-dirty implementation. In other words, it’s a lot dirtier than first imagined. Quick-and-dirty is never a good idea and never as cheap as first proposed.

The one option that is often overlooked is the option to do nothing. Since most mandates to organizations carry civil rather than criminal penalties, no one is going to go to jail over non-compliance. When the fine for non-compliance is low or even undefined, sometimes the correct course of action is to pay the fine when levied and invest in projects with higher payback. It is vitally important to understand the deficiency in the enterprise architecture and to constantly evaluate whether changes in the regulatory environment dictate reconsideration of the enterprise’s lack of action.

Software Rots!

Date: November 25, 2012 Author: Jeff Comments: Leave a reply

Most enterprises are sitting on a ticking time bomb and the Business Leaders either don’t know it or are not allowing their IT staffs to do anything about it. This is the risk of major computing systems that run the business every day stopping because some change was introduced into the environment usually to address some unrelated issue. For example, it happens every month when Microsoft releases its latest Windows patch set. But Microsoft is not the only culprit.

I once worked with a manager who told me, “Software rots!” (Parke, I’m giving you credit here in case you ever read this post.) Parke’s epithet was generally a retort to someone who had a piece of code that suddenly stopped working for no apparent reason. He knew that something had changed, it was up to the programmer to figure out what it was and why it broke his code. Even then, as in today’s computing environments, there were so many incremental changes happening at various levels in the computing environment that there was always some cause for every effect and hence, a reason for every failure.

I call this software atrophy. Atrophy is actually a term in biology. Wikipedia defines atrophy as the partial or complete wasting away of a part of the body. A major cause of atrophy in muscles is lack of use or lack of exercise. I apply this to software when the technology employed in a system is not kept up-to-date. This can cause it to become incompatible in an ever-changing computing environment. The risk is that Microsoft or some other vendor of software tools and operating systems will patch their product to fix a problem and simultaneously break a function in an enterprise’s production system that is critical to their operations. It happens all the time.

The proliferation of software development tools aimed at end users is largely responsible for this situation. The number of user-developed systems that have become mission-critical in day-to-day operations is astounding. Often, the authors of these systems have moved on from the organization and the current users only know how to use the system, not how to care for it. When it breaks, it becomes a production problem whether the IT department knows about the system or not.

End users are not the only source of this risk. IT departments have similar issues particularly with one-off systems they wrote to solve some operational need that could not be addressed at the time in the enterprise systems. Unless these systems have been maintained to keep their underlying technologies up-to-date, the dooms-day scenario is one month away when the next patch set comes out. Typically, the IT staff who developed these systems have moved on leaving the each of their systems without someone who cares for them. The more systems that used the affected old technology, the more carnage that last patch will cause.

It is well within an Enterprise Architecture strategy to identify and manage this type of risk. It’s not sexy, but it is vitally important. It is in fact a foundational activity for establishing an Enterprise Architecture program that yields high benefits in the short-term. Producing a risk analysis of the probability for a dooms-day scenario after a vendor patch set has been applied is a major component of the value proposition for an EA program. This is what Business Leaders want, so it’s a great way to get established.

Don’t Fire the Person Who Told You How to Eliminate their Job

Date: November 21, 2012 Author: Jeff Comments: Leave a reply

The scariest thing workers face in a business process re-engineering project is the prospect that their jobs will be eliminated. The current economic climate makes this particularly scary because the prospects for them to find another job are not good. However, the BPR analyst needs to have complete understanding of the current process and the expert sources of the required information may think they are the least incentivized people to provide it. They do not want to help you eliminate or change their jobs when they know their next stop could be unemployment.

The incumbents in any job are the recognized experts in the current process. They know why things are done and they often know ways to eliminate work. They don’t speak up for two reasons: no one asked them and they are uncertain of the repercussions.

So ask them! Find out what they do and why. Once you ask them, they’ll probably tell you everything you want to know. The important thing is to focus solely on the work they do and not on redesigning the process in front of them. It is fair to ask them how they would improve things. Make sure the current process and any suggestions for improvement are well documented. Make sure you know who contributed what information.

Let’s fast forward to the end of the project when a new process that eliminates unnecessary steps is implemented. If there are job eliminations, it is imperative that you not lose the people who were instrumental in helping you design and implement the new process. I have two reasons for this position:

Eliminating people who helped the enterprise improve itself sends a bad message to the remaining employees both inside and outside the affected area that helping is a bad idea.
The enterprise loses a valuable resource who is willing to place the future of the enterprise above their own needs. Enterprises need more loyalty these days, not less.

A better approach would be to find another job for the most helpful workers and to include a bonus or a raise in the transition. You should also tell them that should they figure out how to better do their new job, that you’d do the same thing all over again. In other words, show them they will be rewarded every time they help the enterprise improve.

So, we’re keeping the people whose jobs we eliminated because they helped us. But in order to realize the savings of the process improvement, we need to eliminate some people. I would start that process by looking up the chain of command for the manager who knew or should have known how to do it and never did. This is a person who is costing the enterprise more than the value provided.

EA Implementation: A Process, not an Event

Date: November 18, 2012 Author: Jeff Comments: Leave a reply

Every discussion group focused on Enterprise Architecture has a discussion about the length of time it takes to implement an EA program. It is the extended period of time between initiation and the first tangible benefit that turns many Business Leaders off. Successful EA programs demand participation from these Business Leaders. They on the other hand only dedicate time and resources to initiatives that meet their goals which are often short-term in nature.

Why do EA programs take so long to bear fruit? I think the major reason is because most EA programs focus on the future rather than the present. It is much more interesting to chart the course for a glorious new future operation than it is to fix the problems with the current. A great future state is often thought to be the panacea for the enterprise allowing it to abandon all of its current problems. It takes time to figure out what this future nirvana looks like and the process steals resources, often the smartest ones, needed to run the business now. Meanwhile nothing meaningful happens to the current or the future state until the analysis, design, implementation, and conversion work for the future state is completed. These are very high risk programs because the long timeframe makes the final state a moving target.

Business Leaders are risk managers first and foremost. High risk projects do not capture and hold their interest. The strategy for any EA implementation should be to provide immediate value through incremental verses wholesale change. Incremental change suggests that EA implementation ought to be a process rather than an event. The process however, must produce real, attainable benefits along the way. This begs the question: What is the process for implementing an EA program?

We’ll discuss that as we go along.

What We’re Suppose to Do versus What We Do (Part II)

Date: November 15, 2012 Author: Jeff Comments: Leave a reply

My observation is that business people seldom know what they’re supposed to do. They think they are doing what they’re supposed to do and they are experts on what they do. Being experts gives them comfort and meaning. The extra work they have added to the essential process gives them a sense of job security whether they do the actual work or manage the people who do. Any threat of changing what they do will rob them of that comfort and security.

The most productive thing an Enterprise Architect or other business process improvement facilitator can do when working with line-of-business people is to let them describe and defend their current process. They want to tell you how expert they are. The facilitator is there to facilitate the extraction of information, not to impose a solution. The information provided by the business “experts” will serve to map the current state of the process and will also provide important information about the problems that prevented them from attaining an ideal process state in the first place.

Formulation of a future state based on what we’re supposed to do starts as a backroom exercise using the essential requirements gathered at the enterprise level and the business rules dictated by them. Arriving at the appropriate future state will be an iterative process but it is essential that the first iteration be as bare-bones as possible.

The future state model is refined using “gap” analysis. Most people think the product of gap analysis is to create things that fill in the gaps between the current and future states. That works fine if the future state is “bigger” than the current. However, you must eliminate gaps when the future state is “smaller” than the current. The information provided by the business “experts” is used to determine whether an extra process is extraneous or more essential than first believed. Once you have filled/eliminated all of the gaps, it’s time to review the new process with senior line management. This may also be iterative but you must keep iterations to a minimum. Line management must be aware and buy into all changes before they are reviewed by the “experts”. You will need the managers to help persuade the experts that life will continue after the process they love so dearly changes.

The final set of iterations involves the business “experts”. This will be a highly charged set of sessions because the stakes are high for people who derive their worth from processes you think can be eliminated. If you have done your work correctly, it will be evident that unnecessary activities can really be eliminated.

What We’re Suppose to Do versus What We Do (Part I)

Date: November 11, 2012 Author: Jeff Comments: 1 Reply

Unless you are an artisan, the best way to do something in your business is to make it efficient and repeatable. Artisans thrive on the unique and exceptional. That’s too expensive for everyone else.

Let’s borrow two terms from manufacturing:

Factory Process, generally called a continuous process, is noted for repeatability, large scale, speed, and efficiency. Consistent inputs go in and are processed the same way everytime before coming out as a uniform result. Rigor is built into the process so it is as simple as it can be.
Job Process is noted for uniqueness, small scale, indeterminate timeframes, and inefficiency. Inconsistent inputs go in and are processed different ways resulting in inconsistent outputs. The more rigor we attempt to place on the process, the more complex it is.

Most enterprises are riddled with job shop processes. Just try to model any process in your business as an essential string of events and your business people will start telling you why it’s not like that in the real world and how they really do it. I have a name for both: “what we’re supposed to do” and “what we do”.

“What we’re supposed to do” is really very straight-forward. When given a fresh look, business processes can be based on a very succinct set of requirements. It often represents a new way of doing something that has become enabled because we are doing something upstream better or we are leveraging a new technology.

“What we do” evolved because it’s what we’ve always done. It doesn’t take into account only the essential requirements but rather all of the exceptions that have appeared, been nurtured, and then institutionalized over the years. It also doesn’t leverage any efficiencies made available by upstream changes or technology. It can often impose obstacles on the upstream improvements and it only uses technology so more of it can be done faster.

“What we’re supposed to do” is as close to a factory process as we can make it. “What we do” is a job shop process. We’ll look into this more next time.

Skills Required from an Enterprise Architect

Date: November 8, 2012 Author: Jeff Comments: 1 Reply

Enterprise Architects are management consultants. They must be able to work with senior-level Business Leaders and focus on business issues.

All business problems originate from a lack of focus or attention to detail. As businesses mature and expand, the amount of information bombarding Leaders increases to the point of overload. Leaders cope by moving from details to summaries as input to their decision-making processes. Much valuable information becomes lost in the abstraction.

The Enterprise Architect must help these Leaders manage their access to the data that really matters. They must also maintain a model of the current state of the enterprise and a view to where the enterprise wants to go.

What is Business-driven Enterprise Architecture?

Date: November 4, 2012 Author: Jeff Comments: 1 Reply

Business-driven Enterprise Architecture = Requirements Satisfaction + (Risk Management + Transition Management)

Business Leaders care about making sure their businesses operate successfully and profitably. That means they care about making sure they are doing what they are supposed to be doing, that they manage the risk when they are not quite on target, and that they can easily transition from event to event through their business’ life cycle.

Business-driven Enterprise Architecture focuses on producing information that helps Business Leadership to do the things they’re supposed to do: run the business, manage risk, and manage transition, by determining all of the requirements and understanding all of the business’ assets.

This is a strategic business planning and oversight function.