All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

Delegation is a difficult skill to master. Many managers confuse it with tossing work over the transom and forgetting about it until the deadline. That’s a weird mistake to make when you think about it, given the absence of transoms, not to mention doors, in the modern workplace.

One way to think about the role of IS in the enterprise is that the business has delegated management of technology to it. Most businesses have tossed the task over our virtual transom and wonder why in their eyes we often botch the job.

When someone uses your transom to delegate to you, your proper response is to insist on meeting to make sure you understand the purpose, scope, and time frame of the task.

That’s why, in our continuing development of an integrated IS plan, we spent so much effort learning about the company’s strategic, tactical, and infrastructure goals. That was our means of understanding the purpose, scope, and time frames associated with our responsibilities.

Now that we know about ’em, what are we going to do about ’em? We’re going to change our architecture to satisfy them, and our starting point is supplying applications that satisfy the company’s requirements for process automation. (No, not databases that satisfy information needs. They come later. It’s the applications, processing information in our databases, that provide business value.)

Your applications suite needs regular review and grooming. Especially, you need to go beyond assessing the current business value provided by each application. What you’re trying to do is determine how well your current mix of applications supports the future state of your business, and what changes you can make to support it better.

You can be as informal or structured as you want in making this determination. Here’s a framework you can use as a starting point.

Begin by identifying key business functions – major activities, like marketing and manufacturing – based on how you expect the company to be structured in the near future. (Don’t be too abstract. If you have multiple business units and each has its own manufacturing operation, count these as separate business functions.)

Next, inventory the application systems you support. That’s right, all of them, not just the ones you think are important. You’ll have to make some arbitrary decisions on what constitutes a “system” – is your enterprise resource planning solution one system, for example, or do you deal with its HR/payroll, manufacturing, and accounting modules separately? Rule of thumb: If you can’t replace it as a unit, it isn’t a system. If you can, it is.

Set up a matrix (you saw that one coming). The columns are your business functions; the rows are your application systems. Put two scores in each cell: (1) How important the application is to the function; and (2) How well the application fulfills its role. If you’ve implemented a GUI shell that shelters end-users from the underlying computing environment, set up two matrices – one that describes the end-user experience, the other that describes the underlying applications environment.

To use the matrix, look at how well your applications support each business function. How well each application fulfills its role has an obvious impact. The number of applications required is also significant—the more applications required (weighted by importance) the less satisfactory. Count each application’s market viability in your assessment of how well it supports a function – you can’t count on orphan products to survive compiler and operating system upgrades, so by definition they don’t support your future business.

The computations you use in your assessment depend on your appetite for mathematics – you can create a formula that takes all factors into account and behaves properly, but it won’t be a simple one.

Compare your computing environment to “perfection”: a single system that supports the entire enterprise and is perfectly adapted to your business requirements. That obviously isn’t achievable, but every step you can take that improves the fit between applications and requirements, reduces the number of applications with which end-users interact, reduces the number of applications you have to support, and minimizes the risk of conversions is a step worth taking.

Comments

|In: Architecture|Last Updated:

A decade or so ago, John A. Zachman published a seminal article on technical architecture in the IBM Systems Journal. (In publishing, “seminal” means lots of people cite it but almost nobody actually has read it.) Almost immediately, IBM issued a ton of press releases whose only significant impact was to verb the word “architect,” which hitherto only had only been nouned.

The Zachman Framework for Enterprise Architecture continues to be popular among systems theoreticians, and it is largely responsible for popularizing the idea that management of technical architecture has become a key responsibility for IS organizations. It’s an important idea because without it you end up with a junk-filled data center, databases containing conflicting information, and a hodge-podge of applications that satisfy departmental requirements without supporting the enterprise as a whole.

The Zachman Framework may even have something to do with the framework presented in this column last week. My own ideas about technical architecture evolved in happy ignorance of Zachman’s work, and the methodologies don’t seen very similar, but my platform, information, and application layers described last week match up reasonably well with his network, functions, and data.

Pick the framework you like or invent your own. However you take on the subject, focus on keeping your architecture management practice simple enough that you can afford to do it, clear enough that everyone in IS can easily understand it, and practiced as a value-adding discipline, not as a collection of inflexible, bureaucratic rules. You want people to adhere to the architecture because it’s the best way to do business, not because the architecture police are standing on every corner waiting to shoot violators.

The first step in constructing your architecture is to translate your company’s strategic, tactical, and operational goals into an overall organizing principle on which you can hang your future architecture. Having a clear organizing principle keeps things neat and tidy. But how?

Chances are, you need to deliver more capabilities than you provide today, and with greater integration.

It’s a shame that these two requirements conflict, but they do, because in most IS shops, “integration” means creation of custom interfaces between every two items that need to communicate. As the number of items and need for integration increases, the number of custom point-to-point interfaces increases exponentially.

Which means the organizing principle for most IS shops today should be the creation of an integration-centric technical architecture – one that facilitates integration in all three architectural layers.

Things become even more straightforward once you realize you only have two ways to build an integration-centric architecture.

In some circumstances you can choose a core application – maybe an enterprise resource planning (ERP) suite – and make it the heart of your architecture. Rather than creating point-to-point interfaces between every two items that need linkage, you use this core application as the architectural hub of the enterprise and integrate everything else with it.

That’s great if someone sells a core application that fits your business well enough, or if one of the ERP suites supports enough of your company needs. In an era of business diversification, mergers, and acquisitions, though, many of you will conclude that building around a core application just isn’t feasible.

The alternative is to build an integration engine. The idea is simple enough – everything plugs into it, and it handles all of the translations. I presented this concept to a client a while back though, in the form of a PowerPoint slide showing all legacy and proposed applications and databases plugging into a central cylinder. “But Bob,” scolded the DBA, “that isn’t drawn to scale!”

True statement.

Designing and building an integration engine is a highly complicated exercise. If you go that route, don’t every use the words, “All you gotta do is to … .”

Instead, tell everyone involved in the decision, over and over, that your goal isn’t to make things easy. Nothing will make things easy.

Your goal is to take something that’s impossible and make it merely very difficult.

Comments