Daddy, What Does an Enterprise Architect do?

I am an Enterprise Architect. I help companies migrate data centers. That can mean moving from one city to another, or it can mean upgrading their existing data center to newer hardware, different or more current versions of applications and middleware; or it can mean moving from in-house platforms to the cloud. The title Enterprise Architect (EA) can be daunting; the concept is relatively new to our discipline. There isn’t much written  describing how it fits conceptually into the various roles that comprise normal IT operations. Over dinner, I described what my job is to a friend by using this analogy:

Suppose you wanted to move from one house to another. Typically you would pack everything up, rent a truck or schedule a moving van, load it up, drive to the new house, unpack everything, get settled in, and maybe go back to the old place and clean it out. The Moving Architect would figure out the number of different types of boxes to buy, for books, for clothing and bedding, for the china, for any art. The "bill of materials" would list the furniture, the number and sizes of the boxes, and any other items needing special handling. The Moving Architect would suggest how big a truck to rent, how many movers to hire, how long the move would take, and how much it would cost.

Moving a data center is more complicated.  Most organizations cannot tolerate an extended outage, so the challenge is more like moving from one house to another without disrupting the daily routines of the people living in the house, and the people who help out at either house like the landscapers, the realtors who want to show the old house, and the trash collectors whose vehicles can not be blocked.

The Enterprise Architect has to consider the family’s daily activities. When does the bus pick up the kids? On moving day, will the kids know to get on to the new bus to take them home to the new house? The EA needs to know which days are school days and which aren’t, and which days the kids might have after-school activities and how long they might take. To move non-disruptively, the EA will stock the fridge and the cupboard in advance, but some foods spoil over time, so that preparation step has to be timed to not waste resources.

Since moving furniture cannot happen instantaneously, the EA will have to fit out the new house with furniture, bedding, towels, and some clothing in advance. The EA has to make sure the utilities are on and the home is ready to occupy. And in preparation for the move, the EA has to lead the family in a dry run for the move, without interrupting their normal daily activities. The EA will provide documentation on how to use the new home features.

The Enterprise Architect has to understand the patterns of use of the IT resources across time, to create a safe, secure, recoverable plan to migrate work non-disruptively from one set of IT infrastructure to another. So the EA will ask questions of the workers that seem as trivial and pointless as asking the kids what they want for breakfast: if the answer is oatmeal, then the shopping list needs to be updated, the utilities have to be up and in place, the cookware that was used on the old gas range may have to be replaced to avoid damaging the new electric radiant heat ceramic stovetop, and the recipe may need to be updated to accommodate that new stove’s different heating and cooking times. Knowing how the IT resource is used in detail helps the EA guide the migration.

This analogy is structured specifically to evoke parallels to the Zachman Framework. What does an Enterprise Architect do? The EA generates an optimal isomorphic mapping of one instantiated Zachman Framework into another.

Time to Prune those Processes

Anyone who has worked in IT for five years or more knows the truth of the statement: “If you automate a mess, you get an automated mess.” What can we do, and what should we do, about these productivity-sapping kludges? This discussion offers a few short-term actions and some useful longer-term approaches to get some of that productivity back.

One common automation shortcut is to transplant a paper-based process into an exact copy on web screens. The screens look just like the original paper forms, and the process reproduces the exact steps that people used.

The rationale for this relies on the “ease-of-use” and “proven design” fallacies. The business automated the process because it was inefficient, or overly burdensome, or got in the way of needed changes in other business activities. “Ease of use” in this case really means “no learning curve,” which is supposed to reassure the business area that none of their people will have to learn anything new or different. It presumes that the original system was easy to use. Often it was not.

“Proven design” in this case means, “we don’t want to do any business process analysis.” The savings in design and analysis will shorten the front-end of the implementation process, but by not making the design explicit, those well-worn processes remain obscure. This is a problem because unless the implementation team accurately describes the process, the translation from hard copy to soft-copy will create defects. How could that be? In manual processes, users learn to avoid many options they should not take. In computerized processes, the software must handle every possible decision a user could make. The implementation team does not understand that tribal lore the users follow. The implementers must guess what to do in every undocumented case.

That is, the implementation team ends up doing business process analysis under the worst possible conditions:

•          They do not have the skills to do the job
•          They do not have the time to do the job
•          They do not have the tools or procedures to do the job
•          They do not have formal access to user experts to help with the job, and
•          They are not evaluated on how well they do the job

Another way to state this is to observe that every system has an architecture. The only question is, does the implementation team know what it is before they begin? The default architecture is inconsistent and incomplete.

Rushing to get from the old (paper-based) process to the new (automated) process on time, the IT organization abandons its core competence, which is to make complex processes clear. Fixing a kludge like this means first identifying and removing gross process inefficiencies, then second streamlining inputs and outputs.

One easy way to find and fix inefficiencies is to measure the elapsed time that process steps take, and use that measurement to extract any activities that are not adding value to the underlying business activity. For instance, some organizations automate approval processes, replacing a physical form with an e-mail link to an approval web page. Look at how long each approver spends on each request over a few weeks. If you find that a person always approves a certain type of request, and does so within 30 seconds, you can conclude that they are not adding any value to the process. They probably got approval rights because they wanted to be aware of requests. The solution is to replace the “action” link with an “informational” link – and not hold up the process by waiting for that rubber stamp.

Streamlining inputs and outputs can save lots of processing time and complexity. Some paper processes produced intermediate reports to measure a team’s workload. Automating these reports and – what is worse – evaluating a team based on that measurement, locks in the original inefficiencies. Every output should have a natural “consumer” who needs that information to do some other job. The other job may be in-line, meaning it waits for the output before it can start, or it may be cyclical, meaning that at some future time the other job starts using a collection of those outputs. Users regard the in-line type (sometimes called “straight-through processing”) as the real application. They may overlook the cyclical type because they do not usually do that part of the work, such as aggregating financial results, auditing, or quality assurance.

By giving the supervisor a measure of the activity, rather than a copy of the results, the process lets the supervisor focus on the business value of the activity rather than the sheer mass of the activity. This moves towards that oft-sought alignment between the IT organization and the business. If the business gets its job done with little extra activity, few procedural glitches, and optimal efficiency, the IT systems that support it are by definition aligned.

It is now spring 2013, a good time to consider pruning those processes.