Ron Tolido, Capgemini, on (or not on) open BA methodology #ogtoronto

Ron Tolido of Capgemini presented on the case for an open methodology for business analysis. There’s a big component of standardization here, particularly a shared language (terminology, not necessarily natural language) to enable collaboration. He considers the core competencies of business analysis to be information analysis, subject matter expertise and business process management, there’s also an aspect of consultancy around managing change.

In spite of his categorization of BPM as an “IT tool”, he highlighted the importance of process in business analysis today, and how process orchestration (although he didn’t call it that) and business rules can create applications much faster than before. This allows business rules to be changed on the fly in order to tune the business processes, and the creation of configurable user experiences by non-IT people.

Echoing the confusion of the previous presentation on the IIBA, Tolido stated that business architecture and business analysis are different, although business analysts might be involved in business architecture work without being business architects themselves. It appears that he’s making the distinction of business analysts as project-specific resources, and business architects as enterprise resources, although it’s not clear what functions or capabilities are different. There was a lot of audience interest in this issue; there appears to be the will to combine the disciplines in some way, but it’s just not there yet. I’m not sure that there’s sufficient common understanding of the term “architecture” as it pertains to non-technical disciplines.

Kathleen Barret, IIBA, on the Business Analyst role #ogtoronto

Kathleen Barret of the International Institute of Business Analysis discussed how the role of Business Analyst moved from assistant Project Manager and scribe to the focal point for understanding and articulating the business need for a solution or change.

She started by talking about why there is such a strong case now for business analysts. Organizations have been designing solutions for years without proper business analysis, resulting in a spotty success rate; in today’s economy, however, no one can afford the misses any more, prompting the drive towards having solid business analysis built in to any project. There’s also a much stronger focus now on business rather than technology in most organizations, with business strategy driving the big projects.

IIBA was created 5 years ago to help support business analysis practices and create standards for practice and certification. Its goals are to develop awareness and recognition of the BA role, and to develop the BA Body of Knowledge (BABOK) to support BAs.

Business analysis is about understanding the organization: why it exists, its goals and objectives, how it accomplishes those objectives, how it works, and how it needs to change to meet its objectives and future needs. As Barret points out, there’s a big overlap with what business architects do (she posits that they are now the same, or that an enterprise business analyst is the same as a business architect – I’m not sure that IIBA has a well-thought-out position on this yet); the difference may be purely a matter of scope, or of general analysis versus project-specific analysis.

The BA works as a liaison amongst stakeholders in order to elicit, analyze, communicate and validate requirements for changes to processes, policies and systems. This could be at the enterprise level – probably what most of us would refer to as a business architect – or at the project level. This can be a subject matter expert or domain practitioner (which I don’t consider a true BA in many cases) or a consultative BA who works with SMEs to elicit business requirements. In a large, complex organization, there may be several types of BAs: there is a need for both specialists (in terms of business vertical, methodologies and technologies) and generalists.

IIBA will continue to extend the BABOK, and will be releasing a competency model by the end of 2009 to help BAs identify gaps in their capabilities and to help organization to assess current needs and capabilities. In my experience, “business analyst” is one of the most over-used and misused term in business today, so anything that IIBA does to help clarify the role and expected capabilities has to help the situation.

David Foote on EA careers #ogtoronto

Foote presented some interesting – but for this primarily Canadian audience, not completely relevant – statistics on US unemployment; he added the comment “I assume it’s the same in Canada”. Would have been good if he had actually taken 5 minutes to research our job market before presenting here, because there are some significant differences, although many similarities. He followed this with the rather obvious observation that there is always a shortage of talented people with specific skills, and that in an economic downturn, companies are looking to hire quality rather than quantity.

He brought forward recent Gartner research that showed that more than half of EA programs will be stopped in 2009, and that the remaining ones will embrace cloud computing but will struggle with framework and information management problems. Foote pooh-poohed this, and said that there were only a handful of good analysts out there, and that this was not based in fact. The implication is, of course, that he’s one of those good analysts. 🙂

There’s some pretty interesting numbers about pay scales for architects in his research, which was gathered from cities across the US and Canada: although there are a lot of people out of work and salaries are going down, architects with certain certifications are holding steady or even increasing their worth. Whereas the value (presumably measured by pay) of web developers has dropped by over 28% in the past 12 months, architects and project managers – which were, inexplicably, combined – increased by over 4%. Topping the list are Check Point Certified Master Architects and Microsoft Certified Architects, each of which increased in value by 20% in the past 12 months. There are some non-certified skills gaining in value, too: I’m not at all surprised to see process leading the pack at 8.3% increase, since an economic downturn favors process improvement projects.

He showed us some detailed stats on pay scales for architects across a range of US and Canadian cities, and summarized for each country: enterprise architects, data architects, information architects, senior applications architects, applications architects, security architect and director of architecture. He presents these (and therefore architecture in general) as purely IT roles: this is all in the context of IT pay scales, and contains nothing on business architects.

The presentation finished with some of the barriers to enterprise architecture:

  • Many EAs live in a siloed world, funded by business silo, and are expected to bridge silos with “nickel and dime” funding
  • There is a disconnect between IT leadership and EA governance, with many CIOs focused on short-term operational demands versus long-term optimization
  • EAs will have to go through various stages of maturity before their job potential is fulfilled
  • The EA role is not defined well enough to model and operate a successful EA organization

This last bit was interesting, but didn’t really flow from the remainder of the presentation, which presented the IT architect job and pay survey results.

Minaz Sarangi, TD Bank, on EA in financial services #ogtoronto

I still haven’t posted my notes from yesterday – I made the mistake of not bringing my laptop yesterday, and my notes are trapped in my paper notebook until I get a chance to review and transcribe them.

I only caught the last 10 minutes of Minaz Sarangi’s presentation due to a meeting elsewhere, but was able to download the presentation and get caught up in time for the Q&A. TD has grown significantly through mergers and acquisitions, including the major acquisition of Canada Trust in 2000, and a big part of their enterprise architecture efforts are to standardize across the various IT infrastructures that exist in the subsidiaries in order to simplify the platforms. This is not fundamentally different from most large financial services, although in many cases, the acquired companies are run as siloed business units, leading to inefficiencies and inability to provide a complete customer view across all product lines.

TD, in developing a true enterprise architecture strategy that spans all the business units, is having the business strategy guide their EA efforts and their enterprise technology strategies. They’ve developed architecture domain practices for business, applications, data, security and technology, and define prescriptive architectures in order to align solutions delivery with their enterprise standards. All of the technology building blocks are defined in the context of the EA, and each has both a strategy and a reference architecture in order to articulate the current and future state, the roadmap, current and future capabilities required, deployed solutions associated with the capabilities, reference implementations, and technology standards.

From a business standpoint, the key goals are to make employees more productive and to enhance customer experience, but there’s also issues of risk reduction, security, system availability and cost reductions due to standardized technology platforms.

How TD is achieving this is through what they call “EA simplification”:

  • Reduction of operational footprint for greater agility, through application rationalization and enterprise shared services
  • Consolidation and standardization of core technology platform for scalability
  • Automation of repetitive architectural and engineering processes for sustainability, for risk reduction and process optimization

They’re starting to see some success with this approach, but as can be expected from such a diverse organization, it’s slow going. They have some enterprise shared services, including content management, and are getting the sponsorship and commitment in place that they require to push forward.

I’m of two minds about programs like this: I certainly see the need for technology standardization within an organization, but it seems like some of these massive EA efforts serve to just extend the delays for new technology implementation and create a significant set of rapids in advance of the still very waterfall methodologies.

The Open Group Conference

I was already planning to attend the Open Group Conference in Toronto next week to catch up on what’s happening in the enterprise architecture space, and now I’ve been invited to join Dana Gardner’s panel on Monday morning, which will also be recorded as a podcast. The panel is on architecture’s scope extending beyond the enterprise, bringing together elements of EA, SOA and cloud computing. Also on the panel will be John Gotze, president of the Associate of Enterprise Architects, and Tim Westbrock from EAdirections. There are big aspects of business process to this, specifically when you start orchestrating processes that span the enterprise’s boundaries, and I hope that we’ll have time to explore that.

I’ll probably be at the conference each day to check out some of the other sessions, and I may stick around for some of the evening events, such as CloudCamp on Wednesday. If you’re there, drop by my session and say hi.

TOGAF V9 Enterprise Edition

I recently had a briefing from The Open Group’s CEO Allen Brown and Judith Jones, CEO of the UK-based consultancy Architecting the Enterprise, on the new version of the TOGAF enterprise architecture framework announced today.

For those of you not up on your enterprise architecture, TOGAF is a product of The Open Group, a standards consortium that’s been around for more than 25 years, with 7,800 participants in 350 different enterprises, including both end-customer organization and vendors. By allowing each enterprise to have only one vote, it tends to level the playing field and allow smaller vendors and customers to have just as much of a voice as large vendors that might normally dominate standards development.

The TOGAF framework is seeing widespread usage since it works together with other EA frameworks and concepts such as model-driven architecture, rather that competing with them. They’ve been seeing a growing demand for TOGAF 8 certified people, of which there are about 9,000 worldwide.

TOGAF 9 was developed in response to the needs of The Open Group’s members:

  • Closer alignment with the business
  • Simple implementation and greater usability
  • Evolution rather than revolution in order to preserve value in existing investments

Version 9 has a number of new features over version 8:

  • Further detail on the Architectural Development Method (the diagram of interconnected circles with activities A-H surrounding Requirements Management), including guidelines and techniques on its usage.
  • Modular structure, promoting incremental adoption and greater usability.
  • Content framework, providing a Zachman-like categorization framework for EA artifacts; in fact, they have a mapping between TOGAF and Zachman since these might be used in the same environment.
  • Explicit consideration of architecture styles, e.g., SOA.

They’ve added quite a bit more material to TOGAF in this version, plus enhanced certifications. The certification program for TOGAF 9 is exam-based (rather than the current training-based certification with an optional exam), with 2 levels of certification: foundation and advanced. There’s also an exam to recertify people from TOGAF 8 to 9.

The biggest adoption for TOGAF has been in the UK and North America, which is likely driven in part by language translation of the materials, but there are other organizations in Europe, Australia and Asia starting to use it as well.

Appian Forum: MEGA Partnership

Terry Lee, MEGA’s VP of North American operations, gave us an overview of MEGA, both in terms of their business process analysis and enterprise architecture capabilities. He stated the real reason for using a BPA tool, rather than just the modeling environment within the BPMS, is the ability to analyze the processes within a larger context: relative to risk analysis, enterprise architecture, and corporate performance management.

A process is analyzed and some level of design is completed in MEGA, then the process is handed off to Appian through a manual export/import for further work in their process designer — no mention of round-tripping, although I happened to be sitting beside Dan Hebda (MEGA’s VP of technology) and passed him a note asking about this. He replied that round-tripping would be supported, but isn’t in the current prototype that they’re demonstrating here at the conference. I have a meeting with Dan tomorrow at Gartner, where I’m sure to get a lot more information on this, and Terry summed at the end of his presentation by mentioning that the future integration would include round-tripping.

Metrics for the executing process are captured using the MEGA Advisor and fed back to the models in MEGA to allow for process analysis and optimization.

I believe that there’s a lot of benefit for many organizations in using a BPA tool such as MEGA for modeling processes — especially the portions of processes that are not automated, hence may not be represented in the process models within a BPMS — and the larger enterprise architecture context. For success, however, this requires two key areas of integration: a seamless bidirectional exchange of process models, and the ability to load executing process logging data back into the BPA. It appears that Appian and MEGA are working hard to achieve both of these.

Architecture & Process: Jaakko Riihinen

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.

Architecture & Process: Robert Pillar

The first breakout session of the day was on connecting BPM, SOA and EA for enterprise transformation, with Robert Pillar of Microsoft. He’s talking about how compliance is the key driver to the coalition of BPM, SOA and EA, but that the coalition starts with holistic collaboration. There are barriers to this:

  • Organizational barriers: IT organizations and silos between EA, SOA and BPM groups
  • Cultural barriers: lack of understanding the business value, lack of understanding the concepts, and old-style mentality
  • Political barriers: resistance to change
  • Collaboration barriers: resistance to meetings and collaboration

Risks and benefits must be measured.

At this point, someone in the audience spoke up and said “we understand all this, can you just skip ahead to any solutions to these issues that you have to present?” Incredibly rude, and really put the speaker on the spot, but he had a point.

He had a summary slide on why to choose SOA:

  • It offers a focus on business processes and goals: supports customer centric view of the business, allows design of solutions that keep requirement changes (agility) in mind
  • It offers an iterative and incremental approach following EA and BPM initiatives: make change happen over time, allow employees learn about the concept of services
  • It offers a means to reap the benefits of existing investments on technology: reuse IT resources, focus on business problems without being entangled in the technology

He sees EA and BPM as leading us to SOA, which is a valid point: if you do EA and BPM, you’ll definitely start to do SOA. However, I see many organizations starting with SOA in the absence of either EA or BPM.

Architecture & Process: Rob Cloutier

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.