Column 2 by Sandy Kemsley

Jaakko Riihinen, head of enterprise architecture for Nokia Siemens Networks, spoke about business process architecture: a deep dive into the details of one set of models that they use in their EA efforts. He started with definitions of architecture, process and abstract modeling, reinforcing that a presentation view of a model is just a view, not the entire model. In his definition of architecture, I especially like the analogy that he made of architecture being the external energy that keeps systems within an organization from evolving into chaos. In general, architectures tend to satisfy nonfunctional requirements, such as optimization of system economics.

One of the issues in modeling processes is the different types of models that may be used in different departments, and the ultimate goal is to have a set of process models for the entire organization rather than having them be constructed piecemeal. He characterizes processes in three types: transactional, creative (team collaboration on work product), and community (dynamic, self-organizing); the modeling method that is the focus of this presentation addresses transactional processes.

He shows three elements of their process architecture:

• A process integration model, showing the high-level view of how processes and work products interact. This is the functional design of the process architecture.
• A process behavior model, which is a standard swimlane process model that shows the detailed view of one of the process nodes from the process integration model. It’s different from BPMN in that the work products are shown within the sequence flow rather than attached as artifacts since they are focused on linking the activities closely to what triggers them and what they produce.
• Work instructions for performing one activity in a process.

Other characteristics of a process are also modeled:

• Process instantiations, which can be scheduled or event-driven; where event-driven can be based on work product (e.g., inbound document) or an explicit event (e.g., timeout).
• Execution constraints, either a free-running schedule (activities execute as soon as inputs are available) or an imposed schedule (e.g., periodic reporting)

The process integration model shows the instantiation methods for each process, as well as showing how multiple processes can provide input to another process in a variety of ways, including both informational and triggering.

All of this provides the notational background to discuss the real issue: normalization of process models and process architecture, using methods derived from classic systems methodologies such as control system theory and critical path analysis. The benefits of normalization include unambiguous definitions that are easier to understand, and better recognition and reuse of process patterns, but the real benefit is that this turns process architecture from an art to a science. There are four basic rules for process architecture normalization:

• Structural integrity: closing alternative paths within parallel paths, and closing parallel paths within alternative paths (these are basic topology constraints from graph theory, and would be enforced by most process modeling tools anyway)
• Functional cohesion: no disconnected activities
• Temporal cohesion: no synchronous processing by activities outside the process (which implies that you would not use the BPMN method of separate pools for separate organizations since messaging between pools would not be allowed, but would consider that separate organization’s activities to be part of the process if your internal process needs to wait for a response from the other organization before continuing the process)
• Modularity: activities or roles having different cardinalities belong to separate processes (this helps to determine the boundaries between processes, e.g., sets of activities that pertain to the entire company are usually in separate processes from those for individual business units), variance at the process level (when alternative paths in a process become sufficiently complex or encompass most of the process, create two variants of the process), variance at the integration model level, deployment details, process components (subprocesses shared between processes)

Determining the boundaries of a single process may involve combining what are considered to be separate processes into one: we discussed the example of employee onboarding, which involves several departments but is really a single process. Looking at the triggers for activities and processes also helps to determine the boundaries: activities that asynchronously create work products that are consumed by other activities are usually in a separate process, for example, as are activities that are performed on different schedules.

They’re using ARIS, and have configured their own metamodel for the process integration model and behavior model. Riihinen is also interested in developing automated methods for normalizing process models.

His slides are incredibly dense with information, and fascinating, so I suggest that you check them out for more details on all of this. In particular, check out the slides that show examples of the four process normalization rules.

As you can tell by the above URL, the conference is using Slideshare to publish (but not allow downloads of) all presentations here.

The disadvantage of a small conference is that speakers tend to drop out more frequently than you’ll find in large conferences, and this afternoon my first choice didn’t show. However, it had been a tough choice in any case, so I was happy to attend the session with Rob Cloutier of Stevens Institute of Technology on patterns in enterprise architecture.

The analysis of patterns has been around along time in mathematics and engineering, but they’re often difficult to capture and reuse in real life. There are some real business drivers for enterprise architecture patterns: much of the knowledge about systems is still gathered through artifacts, not patterns, making it difficult to reuse on other projects. It also tends to control complexity, since systems are based on standard patterns, and creates a common syntax and understanding for discussing projects. This has the impact of reducing risk, since the patterns are well understood.

Patterns are not created, they’re mined from successful projects by determining the elements contributing to the success of the projects.

In an enterprise architecture sense, there’s the issue of the level of these patterns; Cloutier’s premise is that you define and use patterns relative to your scope within the architecture, so may be a system architecture pattern. He laid out a topology of patterns relative to the views within the Zachman framework: organization, business and mission patterns at the contextual/scope level; structure, role, requirements, activities and system processes at the conceptual/enterprise model level, system analysis, system design, system test, software architecture, software analysis, software requirements, hardware requirements, hardware design and operational patterns at the logical/system model level, and so on. He focused primarily on the five patterns in the enterprise model level.

He walked through an example with use cases, generalizing the purchase of a specific item to the purchase of any product: the actors, functions and data flow can be generalized, then adapted to any similar system or process by changing the names and dropping the pieces that aren’t relevant. He listed the characteristics of a pattern that need to be documented, and pointed out that it’s critical to model interfaces.

He showed the analysis that he had done of multiple command-and-control systems to create a command-and-control pattern containing four basic steps in an IDEF model — plan, detect, control and act — with the input, outputs, strategy and resources for each step. In fact, each of those steps was itself a pattern that could be used independently.

He had an interesting analogy of the electricity and distribution system as a service-oriented architecture: you can plug in a new device without notifying the provider, you might be served by multiple electricity producers without knowing, your usage is metered for your service provider to bill you for the usage, and the details of how electricity is generated is generally not known to you.

Like any enterprise architecture initiative, the development of EA patterns is often considered overhead in organizations, so may never be done. You have to take the time up front to discover and document the pattern so that it can be reused later; it’s at the first point of reuse where you start to save money, and subsequent reuses where it really starts to pay off. Although many examples of software patterns exist, enterprise architecture patterns are much rarer: Cloutier is researching the creation of an EA pattern repository in his work at Stevens Institute of Technology. Ultimately, the general availability of enterprise architecture patterns that have been created by others — a formalization of best practices — is where the real benefits lie, and can help to foster the acceptance of EA in more organizations.

I like coming to smaller conferences once in a while: although I usually have to pay my own way to get here, the networking tends to be much more real than at a larger one. In the 10 minutes before the keynote started this morning, I chatted with five people who I know, and had one complete stranger introduce himself to me and tell me that he reads my blog. Also, since this conference is focused on enterprise architecture and process, there will be a few people around who appreciate why I call this blog Column 2 (think Zachman).

To get my complaints in early: no wifi (as Michael zur Muehlen was quick to tell me) and no tea. And since this is DC, we start at 8am. Other than that, everything’s good.

Edward Lewis, who was the first CIO of the US federal government, is giving the opening keynote, discussing transformation for the 21st century by tapping the hidden potential of enterprise architecture. He started with how many organizations are seriously out of date in how they operate, and gave a list of "great reasons" not to use enterprise architecture: too complicated, too much change, takes too long, costs too much. However, business wants results in term of organizational and technological change, and Lewis sees four major areas of focus for visionary organizations:

• Not just supply chains: global supply and demand chains that are more complex, synchronized and focused on all processes, activities and technologies
• Strategic partner relationship management for seamless interoperability
• High-performing organizations: people and culture are the most important factors
• Achieving the "perfect order" of total business-wide integration versus the "perfect storm"

He stressed the importance of the global supply chain: not just what you’re doing, but what your supply chain partners are doing that contribute to the timely, accurate and continuous flow of your product/service, information and revenue.

He believes that enterprise architecture has a key role in achieving the breakthrough performance required for visionary organizations, by supporting strategic thinking and planning, and allowing the alignment and integration of people and culture with the business and IT strategies, organizational structure, processes and technologies.

EA is the strategic configuration of business and information resources, a type of strategic decision-making framework.

His ten critical success factors:

• Strong executive leadership: support, commitment and involvement
• Dynamic business and IT strategic planning environment: coordinated, integrated, flexible, long-term strategic focus
• Formal business and IT infrastructure: framework, policies, standards, methods and tools
• Integration architecture models: business plan, organization, data, applications, technology
• Dynamic business and IT processes: macro and micro, internal and external
• Use information and knowledge effectively: all aspects of data and information
• Use information technology effectively: enterprise-wide, fully integrated
• Use dynamic implementation and migration plan: well-defined projects
• Have an innovative culture and access to skilled individuals: education and training, teamwork, culture and organizational learning
• Have an effective change management environment: integrating change programs, high-performing organization

He boils this all down to three factors: people, culture and leadership.