Disaster Recovery is typically years of planning for a major event where pandemic planning is essentially determining which pieces of your business is non-critical so that you may take it down gracefully because you don’t have enough people to run it. How many of you have business processes that are able to facilitate that question?

Years ago, I was responsible for figuring out which databases were critical to an organization I worked at because the century’s biggest flood was coming. What if we had to relocate and run our business else where? Which systems were the most critical and which databases would we need to make available somewhere else? We were situated at the lowest level in the city, and would likely have to move if our core flood prevention methods failed.

Now turn the tables for a minute – if I had a team of ten database resources working everyday to keep the systems supported, two system resources, a security guard and a building maintenance resource, how many could be affected by a pandemic if one should hit my city? Who would decide what needed to move? Or more likely – what database operation or support function didn’t need to get done for some undefinable future?

Now even more likely, if you have a call list, what are the chances that someone on that list would be affected? How would you contact the others to get replacements if the city or area is engolfed in chaos. As the presentation suggested, many wouldn’t want to leave their homes for fear of being affected by others. Do you have a plan in place by your business architecture as to priorities for keeping your minimum technologies running?

Just a few thoughts that got me thinking about what I might suggest to a few of my customers that have been thinking in reverse for years. Business Architectures must be in place and current in order to make such rapid decisions, and the value of these exercises is most often over looked.

Typically, DW projects are initiated without a large concern for much more than the software required for actions such as extraction, transition & loading, modeling and report generation. Building and maintaining such systems require you the architect to either contract for or perform design work to ensure that there is focus on deploying user-driven data warehouses that are based on an enterprise architecture and are scalable, fast, available, and secure.

Integration is needed between operational and analytical systems to support the applications. Six key business goals are needed to ensure that the business intelligence applications that bridge large packaged software applications and data warehouses:

1. User-driven. Unless data warehouses are designed and architected to address specific business drivers, they will not support the strategic applications considered key to your organization.

2. Architected. All business intelligence initiatives should be supported by a common enterprise architecture that standardizes processes, components, and tools. The architecture needs to provide a common systems and application infrastructure that makes it easy generate new data marts and modify and leverage existing applications.

3. Scalable. When you architect a user-driven data warehouse, it typically grows fast, both in numbers of users and volume of data. Huge amounts of detailed data come from both packaged and custom applications that users may want to analyze inside a data warehouse. The correct servers must be included, as well as enterprise storage to manage terabytes of data.

4. Fast. Users always want speedy responses to their queries, but this is always the expectation with any system. Massive systems require powerful servers designed for precisely the purpose of handling complex query workloads.

5. Available. Data warehouses supporting analytic systems will be continuously updated. Users and applications will want real-time information from the previous day, previous hour, or even the previous minute. Loading and backup and restore capabilities must be planned in order to minimize the impact of any unforeseen outages.

6. Secure. If you must open up a data warehouse to external parties and link them with multiple heterogeneous systems, close attention must be paid to security issues. Access control and encrypted data are also considerations that you need to make.

Most maintenance comes from either technology upgrade or business change, hence the need for heightened attention in planning these areas of our system designs and application frameworks. While SOA is the hot topic of the day, it is the “how” that we must carefully watch. Technology and methodology choices will either assist or expose us to volatility in the future.

Languages such as BPEL (Business Process Execution Language for Web Services, should be reviewed and contemplated for use in our designs. It aides us in taking a top-down process approach to SOA. As we prescribed earlier, top down design taking a business rule perspective will be critical in embracing this paradigm shift.

Service Oriented Architecture is ALWAYS business driven, and before we start, we must consider our plan of attack with respect to architecting in the ability to absorb business rule changes.

If this is so important, and a critical area that we must focus on to manage volatility in the IT Architecture, is it so difficult to get buy in and involvement from the business areas. We find it difficult to get a documented strategy within our organizations, and even harder to find business resources that can be committed to creating models and providing business knowledge.

Often business resources that are committed are not given enough authority, or are taken from areas which do not have the authority to put a stake in the ground and claim that a process has been set and will be respected during system build time. Resources that are not senior executives seem to find resistance into claiming “this is how we do it”.

John Zachman has always reinforced that business activity is what provides the organization’s value chain, and modeling it is well worth the effort. We often don’t get started in the Zachman framework as the Mission and Vision statements are his prescribed starting point at the first level within the planning perspective.

Articles exist on the site prescribing some quick starts if this information isn’t available. See the newest tip, or perhaps one of the articles on this topic. The target and goals should be to answer the most basic questions.

1. Who are our customers?
2. What services and products do we offer to them?
3. How can IT support delivery of these services and products in the most efficient manners, or using technology to exploit a market niche or gain competitive advantage?

Together, these first two questions prescribe how we will deliver value to our customer, therefore providing value back to the business areas. Conversely, answering the latter two questions demonstrate how we will achieve value from the business architecture within the IT Architectures – doing the right things to create winning solutions.

Artifacts such as business process diagrams, system functionality matrices, state and activity diagrams as well as use case and class diagrams are the things we must focus on. We don’t ever seem to get here because of lack of resources, appropriate level of support and focus, nor the understanding of the true value that will be achieved.

These models will allow us to project quickly the potential impacts and reduce costs related to business rule and process changes. It takes dedication to push for resources and project budgets to adequately model these architectures, but I promise – the investment will pay for itself many times over

It’s common for me to answer almost the same questions in many different ways – it is definitely time for some food for thought about one common theme.

The theme is that many budding architects understand the basic architecture domains, and now see that the value may lie in the business architecture. Getting started is another story.

“It’s just Business”, as the saying goes, and it just seems so difficult to complete this part of our architectures. I’ve added more content this week to the Business Architecture section, and will try to keep that flow going. In the meantime, let’s put some content into this eZine.

One of the most reusable asset of your IT environment is the business architecture and the models and artifacts collected to build it. It is also the area which is most vulnerable to change, and the business rules contained within your systems and applications are the most volatile.

For most architects, this question seems one of the most hardest to understand.

The focus area of enterprise architecture focused on defining the future state
business model, organization and capabilities/services needed to satisfy ongoing
business transformation efforts.

An Enterprise Business Architecture (EBA) describes the various functions of an
organization, the business processes that support those functions, and the relationship
among the business processes. The EBA includes the current Business Objectives and longer
term Business Strategies of the organization as well as the Business Capabilities the
organization will require to achieve its long-term Strategies; and maps the supporting
business processes and functions.
BABOK Definition (V1.6)

The Business Architecture is a set of documentation that defines an organization’s
current and future capabilities. The Business Architecture describes the businesses
strategy, its long term goals and objectives, the high level business environment
through a process or functional view, the technological environment, and the external
environment.

An INDUSTRY PERSPECTIVE

The term Business Architecture is used for a broad range of very different artifacts and
activities. Vendors have introduced complex methodologies, sophisticated business modeling
tools as well as “meta-languages” for describing a business. We use the phrase ‘Enterprise
Business Architecture’ to denote that we are referring to BA in the context of EA-related
activities

In a number of organizations that are focusing on developing an EBA the lead responsibility
is often in a line organization and the EA team, as well as IT, is often not included
despite that fact that technology is often the key enabler of most business transformation
efforts.

The Business Architecture is a description of the organization and as such is very much
like the blueprint of a building. Its components include descriptions of the
organization’s data (domain data), processes, organization, and places (locations).

Its process / deliverable components include:

Capabilities List/Model
Business Strategy – goals and objectives
Business Drivers
Organizational Architecture
Data Architecture
Process Architecture – Business Process Models
Deployment Architecture
Business Architecture Relationships

Recently I’ve been asked yet again about best practices in writing use cases. I started researching this very topic back in the mid 90′s when there were really only two authors on the subject – Alistair Cockburn and DeChampeaux. They have become the ultimate in theorists, and really don’t make up such lists.

The three amigos have revolutionized use case analysis by releasing the Rational Unified Process, and Information Technologists have embraced their methods for documenting business requirements. Reading the Rational Unified Process in detail is actually your best clue on the subject.

Best Practices…

In discussing the topic of best practices, it is safe to say that there is no right answer to every question. There is a lot of “it depends” when a question is posed “what is the right way to document this in a use case”. There are a few methods, depending primarily on context, and the business environment in which the requirement specifications must be used. Some environments are lacking the role of application designers, so more design details need to be included. Other environments have many distinct roles, and this becomes a pure business documentation exercise.

It is most likely safer to discuss what should never be seen in a use case. If there were such as thing as the Use Case Police, these would be their primary citations:
The first – cutting and pasting legacy code into a use case document – Oh my goodness – do we really need to explain this? It is done so many times and it just shocks me every time.

Although we may have business rules and logic embedded in this stuff, it’s someone’s job to unravel the mess, and guess what – it’s yours! Pull out the business rules, and put the rest into the documentation. There has to be some steps or functions, and they can be documented, no matter how daunting it may seem. I’m not saying that this stuff should never be seen in a document on an OO development project, just not in a use case. Leave this stuff to “supporting documents” or inputs to the use case.

The Second Problem…

The second problem – Including If/Then/Else Logic. Let’s face it – Actors make choices, and they aren’t always sequential. When the actor gets to a cross road, list the options they may take and then return to the “happy path” or the instance you’ve chosen to author in this use case. You can always put links or references to other use cases, extensions, business rules or requirement statements to document your “branches”.

It’s Not Decomposition…

The third situation – making use case writing into an endless decomposition project. A common approach taken when software practitioners first try their hand at use case documentation is to determine the main functional capabilities of a system. No problem yet. The high level use cases are then distributed to an individual or team and they decompose or elaborate it into several more detailed use cases.

There is nothing wrong with this as long as the main goals of the system are kept in mind, and that common functions or actions are extracted and then shared and integrated. Keep in mind that objects are not functions, and functions are not objects. Duplication of effort occurs when one of the primary functions is not seeking out the common components. It is also necessary to document the interactions between the components, which often gets missed when using a decomposition method. System integration is only possibly when the whole vision of functionality is kept in mind.

Remember the Actor???

In no particular order, the fourth situation I’ve seen is forgetting about the actor – Remember the Actor? Yes, the poor little stick dude that this whole world is supposed to revolve around. I’ve seen use cases that forget what this poor little guy wants to achieve. When choosing the “happy path”, or scenario that this use case describes, think about one particular Role (definitely not a position within your firm), and document one instance of a function this actor wishes to provide within your business world.

Never forget why he came here in the first place. Give him a place to start (the good old “this use case begins when”), and definitely do not let him leave the building unannounced (with the ever wonderful “this use case ends when”).

Don’t forget how he got here in the first place by setting context within pre-conditions, and if he supposed to do something when he leaves, why don’t you document that in the post-conditions section? Does the Actor have way too many friends, and not enough attention is paid to the Guest of Honor? You guessed it, pay attention to the Primary Actor in the use case and you will have avoided this mistake.

Now the actor is more important than ever, as the actor becomes especially important when it comes to developing complex systems such as Web services, where external interactions play an important role in the system design. Remember that the actor can also be an external system, and the interactions between systems and services are best depicted pictorially or with models such as activity or sequence diagrams.

Recall the King of the sequence diagram? Who sits atop, reigning over his very own swim lane? – Yes – you guessed it, it’s the actor again. It is important, when we initially conceptualize a system, to identify the actors that will impact that system. Understanding the interplay of requirements and services between our system and its actors lets us allocate system resources accordingly. The actor’s role in a system determines the degree to which it may impact the system.

Don’t Drop Anything!

The fifth problem – dropping the ball – Remember the “hot potato game?” You’re supposed to pass something around pretending it’s hot and do not drop it between yourself and your neighbour. How about “the dangling participle” from your school days grammar teacher? Both of these have something in common with use cases. There can be lots of opportunities to miss a step, or not link them adequately. Each step must flow through to the next, and the reader/developer or designer must clearly understand what is to be achieved.

It’s Not About the Interface – It’s about the Business Problem!

The sixth problem – including too many user interface details. Sometimes, a writer chooses to document a use case in terms of the use interface. Push this button; navigate to here, do that. Instead, pick one actor path and use generic terms to advance through it. Use terms that will work one day when “buttons” are gone and maybe even browsers! Use terms that are common to the business such as “select this” and “save that”. It’s always going to be about choices and ramifications, so document that.

The seventh and final problem listed here – writing the use case without setting context. I’ve mentioned this one earlier, but not in enough detail. A use case is only as valid as the content in which it is written. Think about a play – there is scenery, and sometimes even a narrative about what the actors are about to do. These can be documented in your preconditions and post-conditions. If needed, put some context into your basic description that leads into the entire use case. Use the assumptions section to describe any of those you might need.

This is a Rational Unified Process Business Architecture from the Enterprise Architecture context view. The value of this particular view is that it includes the actors/users, the roles, the process and the artifacts.

“By 2008, 40% of enterprise architects will have primary expertise in business strategy or process engineering” 2004 Meta Group, Inc.

They get it. It took some time, but they get it now. I might generalize and say that most medium size businesses have some sort of architecture function in their midst. I’d go further an say every large business now believes that architecture is the brass ring as far as IT success is concerned.

Why is that? Some might argue that that SOX and Clinger-Cohen in the United States have enacted regulations that force this issue. Others might just say that the world has become technical enough to demand it. Or, we’ve got enough airplane magazines now that use the word.

Let’s be optimistic here – we, as IT professionals finally get it, and that is why. What do we get? That Business drives IT. Period. End of sentence. Business strategy drives enterprise architecture, and business is the pure and simple reason that IT exists in the first place. Enterprise architecture success is determined by corporate and line-of-business managers support.

We have started to group our IT product catalog around services. We have application, technology and operational service portfolios that contact web products such as applications, frameworks, web and internet hosting, as well as customer support. Components are groups into services in each portfolio rather than around business applications.

We are starting to understand leverage and reuse. We are getting a spot at the dinner table when the family discusses business strategy. If we are complete, we will ensure that we have some definition within our IT house walls, of the organization’s environment, its goals, objectives, major programs of action and the resource allocation choices required to execute them.

We seem to understand integration…

An integrated strategy which includes technology is enabling businesses to gain successes as never seen before. When we listen to what the business is trying to achieve, and find ways to enable their desires through technology and they can see it, we are viewed as both compliant and successful. If we are to show up at the dinner table and talk only about new cool technologies, our stock continues to tumble.

Business Executives always go back to the basics when considering strategies. They look at perspectives such as product differentiation and marketing segmentation when considering new strategies. If we can enable them to reach new levels with the use of technology, and speak to how we can help them to arrive at these goals in their terms, they understand, accept and encourage us.

Learn Business Speak

We, as enterprise architects, need to truly understand more business speak. If you are the architect in a commercial setting, take the time to understand some basics. For example, market factors are an excellent area of business knowledge worth knowing. If you spend as some time this month researching various marketing factors such as market entry, product risk, product differentiation and product price positioning in relation to the types of technologies that might be required to implement such strategies, you will have well spent your reading and research time.

I would suggest you spend some time looking at various business decision making techniques, such as Boston Consulting Group’s Product Portfolio Analysis and Porter’s Five Forces Analysis. I’ve spent time studying and using many such models and techniques when I’ve both analyzed and modeled business architectures and share some of this information at my decision making site.

Strategic planning considers business strategic value of IT investments. Learning business strategy yourself will payoff in spades to your future. It is something that may not interest you in theory initially, but when you understand how it relates to technology, you might become much more interested and your stake value will increase dramatically!

– A reprint of an Architect Abstract newsletter article