Practical Business Architecture: Aligning Business and IT

Business Architecture is more than just models and diagrams; it provides the broad starting point for the Enterprise Architecture (EA) process, and contains the whys, whens, and whats of the business strategy and its impact on IT. One of EA's most important goals is to "align business and IT." However, this often proves elusive because it is too "fuzzy" or too difficult. This Seminar demystifies Business-IT Alignment by looking at how alignment can be practically measured in IT Systems and the EA Program.

Even in a hypothetically static world, aligning IT and business at the systems level would require a firm understanding of expected and actual performance. We would need a credible way to assess system performance over some period (or in some set of conditions) and compare it to the business needs. Business needs have to be known, and systems have to be built in such a way that they meet those needs and allow data to be collected to support the assessment. In the event a performance gap exists, the system would have to be improved. A trade-off analysis could be done on the alternatives, informed by the size of the gap, the criticalness to the business, and the implications to the system changes needed to close the gap. Wouldn't it be beautiful!?

Alignment of a system becomes a more complicated issue as we consider the dynamics of the real world: whatever alignment did exist might not continue to exist as the business needs change and the IT capabilities change. Hence, the business expectation that is the goal of the "alignment" is a moving target.

In this in-depth seminar, Cutter Consortium Senior Consultant Jim Watson will describe how to meaningfully measure and assess the alignment of IT and business. You'll discover why the right place to address this is in the Business Architecture. You'll understand how to formulate and describe effective business goals and expectations, and how to capture these in the Business Architecture and apply them to systems.

In addition, Jim will delve into the EA Program as a business function, and its need for measurements to assess success and value. He will review specific measures, such as pre-deployment quality vs. post-deployment quality as assessed by testing, and speeding integration/reducing integration risk by measuring how early in the development cycle integration can be addressed, and he will describe how those measures impact the EA Program and its processes.

Agile Architecture teaches us that while effective Enterprise Architecture (EA) has to have a broad perspective, it also needs to have a focused contribution. There is no more powerful contribution than providing the data that is ultimately used to make specific decisions. As a result of participating in this seminar, you'll be able to mold an agile EA Program that provides real value to decision-making at various levels of your organization, from projects to operations, investment, business, etc. - value that is supported by timely and relevant data that directly addresses "aligning IT and business". As a result, Alignment becomes an actively pursued, measurable goal within Agile Architecture, driven by the overall Business Architecture.

SEMINAR OUTLINE:

The Alignment of Systems to Their Business Goals

In many organizations there is little common understanding of what, really, are the "expectations" that the system is supposed to meet. How can "alignment" be achieved if we do not know what success and failure look like? Jim Watson will reveal a wide range of possible causes for a system to fail expectations, including:

• Requirements - issues of completeness, clarity, change management, etc.
• Development process - issues of risk assessment, task decomposition, user feedback, quality, etc.
• Testing - issues of efficacy, coverage, late-lifecycle testing, etc.
• Architecture/Design - issues of technology usage, integration, systems-of-systems performance and functionality, etc.
• Usability - issues of user processes and system interaction, help desk and system support, etc.
• And many more.

Jim will focus on the non-functional requirements. Why? Because important (and sometimes vague) business goals are expressed as non-functional requirements, sometimes called the "-ilities". And the ambiguity of failed expectations, which is ultimately a statement of user satisfaction, system utility, and alignment, typically falls within the non-functional requirements. You'll discover how putting more emphasis on describing these performance-oriented business expectations as non-functional requirements can create the opportunity to truly measure and assess system performance.

Service Level Agreements: Not Just for Outsourcing

SLAs are widely used as part of IT outsourcing, though they are used less prevalently for systems that are built and/or operated by internal IT organizations. However, they are the perfect tool for describing performance-oriented business expectations and assessment criteria. In this section of the seminar, Jim will delve into the general utility of an internal SLA to describe system expectations, make measurements, and assess alignment. Using two real-world case studies drawn from his consulting experience, Jim will illustrate how the decision-making process is impeded by the lack of system measures, and how (relatively) easy it is to define the measures and collect the data.

Defining an Appropriate SLA

Jim will focus on the IT-side of the assumptions about, and expectations of how, the system will perform when used as expected: How is the system expected to be used? How it is expected to perform? How do we measure that performance to assess whether or not expectations are met? What metrics have to be collected by the system and reported on? You'll understand how at an operational level, the SLA describes what is acceptable for normal behavior, and how many (or how long) deviations can be tolerated with acceptable impact to the business, and how at a planning level, systemic/recurring deviations from the SLA will impact resource allocation (time, money, skills), and how the SLA links to the cost/benefit analysis.

The EA Program as a Business Function

Jim will focus on what it takes for EA to be a business function - what attributes it needs, and how it fits in the context of other business functions within the enterprise. You'll understand when architecture (and other technical activities) rise to the level of "Enterprise Architecture", whereby we assess architecture in a business context.

Measures of EA Program Success

Building on our understanding of EA as business function, Jim will describe practical ways in which the EA Program can be assessed for success. This builds upon, but goes beyond, the traditional maturity model assessment of an EA program. We will look more at what the EA Program means to other business functions - the value provided, the resources consumed, the trade-offs made.