Skip to content

{ Category Archives } EA

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.

2009 02 02 Sandy Kemsley Comments (3)

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.

Tagged ,
2008 09 09 Sandy Kemsley AppianForum
BPA Comments (2)

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.

2008 04 23 Sandy Kemsley Architecture&Process Comments (0)

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.

2008 04 23 Sandy Kemsley Architecture&Process
BPM
SOA Comments (6)

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.

2008 04 22 Sandy Kemsley Architecture&Process Comments (0)

Architecture & Process: Woody Woods

There’s one huge problem with this conference: too many interesting sessions going on simultaneously, so I’m sure that I’m missing something good no matter which I pick.

I finished the morning breakout sessions with Woody Woods of SI International discussing transitioning enterprise architectures to service-oriented architectures. He started out defining SOA, using the RUP definition: a conceptual description of the structure of a system in terms of its components and the services that they provide without regard for the underlying implementation of the components, services and connections between components). There are a number of reasons for implementing SOA, starting with the trend towards object oriented analysis and design, and including the loosely coupled nature that allows for easy interfaces between systems and between enterprises. Services are defined by two main standards (in the US, anyway): NCOW-RM, the DoD standard, and the OASIS reference model for SOA.

There are a number of steps in defining operational activities

  • Establish vision and mission
  • Determine enterprise boundaries
  • Identify enterprise use cases
  • Detail enterprise use cases to create an activity diagram and sequence diagram
  • Develop logical data model

The process for developing a service model, then, the following steps are taken (using RUP terminology):

  1. Identify the roles in a process.
  2. Identify the objects in a process, starting with triggers and results, and refining to include all objects, the initial actions and a complete action analysis, potentially creating a sequence diagram. Other types of process models could be used here instead, such as BPMN, although he didn’t mention that; they’re using Rational Rose so his talk is focused on RUP models.
  3. Identify boundary crossings, since every time an object crosses a boundary, it’s a potential service. By "boundary", he means the boundaries between roles, that is, the lanes on a swimlane diagram; note that some boundary crossings can be ignored as artifacts of a two-dimensional modeling process, e.g., where an activity in lane 1 links to an activity in lane 3, the fact that lane 2 is in between them is irrelevant, and the boundary crossing is actually between lane 1 and 3.
  4. Identify potential services at each boundary crossing, which implies encapsulation of the functionality of that service within a role; the flip side of that is that it also implies a lack of visibility between the roles, although that’s inherent in object orientation. Each boundary crossing doesn’t necessarily form its own unique services, however; multiple boundary crossings may be combined into services (e.g., two different roles requesting information from a third role would use the same service, not two different services). In this sense, a service is not necessarily an automated or system service; it could be a business service based on a manual process.
  5. Identify interfaces. Once the potential services have been defined, those interfaces that occur between systems represent system interfaces, which can in turn be put into code. At this point, data interfaces can be defined between the two systems that specify the properties of the service.

In this context, he’s considering the RUP models to be the "enterprise architecture" that is being transitioned to a SOA, but this does provide a good methodology for working from a business process to the set of services that need to be developed in order to effectively implement the processes. I’ll be speaking on a similar topic — driving service definitions from business processes — next week at TUCON, and it was interesting to see how Woods is doing this using the RUP models.

Tagged
2008 04 22 Sandy Kemsley Architecture&Process
SOA Comments (1)

Architecture & Process keynote: Edward Lewis

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.

2008 04 22 Sandy Kemsley Architecture&Process Comments (0)

TIBCO seminar: Achieving Success with BPM and SOA

TIBCO is holding a series of seminars in various cities, and today they’re in Toronto, where I happen to be at home for a few weeks. Amazingly, there’s free wifi in the Park Hyatt meeting rooms, something that I never expected

We had a welcome from the regional VP, Craig Byar, and an overview by Rourke McNamara of SOA product marketing, but the key speaker was Paul Brown from the Global Architecture group. Actually, McNamara made a great point in his short presentation: organizations with an identified BPM center of excellence (CoE) reported five times greater ROI over those with no CoE or dedicated process team.

Today’s business processes involve many systems, and we’ve used EAI and ETL in the past in order to tie these systems together, but we’ve created a fragile mess of our systems and lost the focus on the business process. It’s hard to . SOA and BPM refine the traditional 3-tier layer of presentation, business logic and data by splitting the business logic layer into processes and services: effectively, BPM and SOA. The service layer can further be split into service operations (the actual functionality of the service) and service access mediation (finding the right service and authenticating access). He also splits the process layer can be split into hard-wired processes (the processes in legacy systems that can’t be changed, or unchangeable high-volume processes such as credit card processing), orchestrated processes (integration-centric processes facilitated by BPEL) and managed processes (BPM), although I’m not sure that I agree on the distinction between the latter two.

We need to separate processes from presentation; too often in the past we’ve embedded processes right in the presentation layer, and since we deliver functionality now through multiple presentation channels (web, desktop application, mobile, web service), the process needs to be in the layer below presentation so that a consistent business process is executed regardless of the presentation channel.

We have a disconnect between business and IT when it comes to developing new systems, and we need to first focus on business processes — the source of business value — to see how they bind together people and systems. There’s an expectation that systems will be developed faster, and this type of splitting of presentation, processes and services helps to facilitate that. However, there needs to be overall architectural guidance and governance for any development project so that things fit together: an architectural review of bot the business process and the systems somewhere between initial requirements and development. The challenge that I see in this model, however, is not to fall back into old-style waterfall development: instituting a requirements-architectural review-development cycle can tend to make the development process less iterative and agile.

There are three key leadership roles in any BPM project, immediately below the business executive sponsor: the project manager, the business process analyst/architect, and the systems architect. I have to say this is true of any business-facing development project, although the business process analyst/architect will be replaced with the particular application-specific analyst/architect role. Brown equates the CoE for a specific technology or application such as BPM, and an overall enterprise architecture team in terms of the mentoring and governance role that they provide. He had a number of case studies of BPM and SOA projects that showed significant ROI, with a BPM/SOA CoE being a key part of each of them.

We all ended up with a copy of Brown’s first book, Succeeding with SOA, and apparently I’ll be getting a copy of his hot-off-the-press second book, Implementing SOA, at TUCON later this month.

We had a quick demo of TIBCO’s process modeling environment, showing the different usages by a business analyst versus IT.

Tagged
2008 04 08 Sandy Kemsley BPM
SOA Comments (2)

Gartner BPM: Getting Started with BPM – Elise Olding

I saw Elise Olding speak at the September conference together with Bill Rosser, and I wasn’t completely impressed, but I think that she was fairly new to Gartner so wanted to take a second look. She’s focusing on three issues in this presentation:

  • How should users assess organizational readiness?
  • How should you initiate BPM and what does a plan for getting started look like?
  • What are the critical success factors to long-term success with BPM?

She breezed pretty quickly past the business process maturity model — again, I thought that Gartner would be focusing more on this — but covered some great points on the importance of corporate culture and change management when implementing BPM: exactly the things that many companies ignore, especially if BPM is being pushed by IT rather than pulled by the business. She makes the point that many factors required for BPM success don’t come naturally to many organizations, and discussed three enterprise personality profiles that determine the approach and goals:

  • Aggressives have an imperative to stay ahead of the pack; they’re trying to seize advantage.
  • Moderates have an imperative to get leverage over their direct competitors; they’re seeking parity in the marketplace.
  • Conservatives have an imperative to catch up with the bulk of the competitive pack; they’re trying to reduce pain and (although she didn’t state this explicitly) probably just stay alive.

She went through the different project roles and the skills associated with those roles: executive sponsor, business process improvement director, business process improvement project lead, design team, subject matter experts, and business process analyst. She drilled in specifically on the executive sponsor role and how important it is to have the right fit: an involved decision-maker with the right motivation and influence across the enterprise.

Next up were the steps for initiating a BPM  project: determining objectives (e.g., agility, compliance), understanding and defining critical processes (e.g., delivering products and services), determining the initial organizational model (e.g., reporting structure for process-specific functions), implementing a “getting started” checklist (14 key project activities that she identifies, e.g., develop business case), and documenting and using the BPM plan (actually just normal project plan/management). She spent quite a bit of time on these five points, and provided a lot of valuable detail and examples; this isn’t rocket science, but it’s good planning strategy that doesn’t add a lot of overhead.

She stressed some key points that apply to any type of IT project, not just BPM:

  • Focus on the right methodology first before selecting even the technology class, much less a particular vendor or tool
  • Projects must be compelling and tied to business strategy, and be prepared to go back at the end and see if the promised benefits were actually achieved
  • Pick the first project carefully: a success here will pave the way for later projects
  • Assign the right resources at the right time, including maintaining continuity of key resources throughout the project
  • Establish governance, but start out with a light touch and add more rigor later

As I mentioned in my review of her previous presentation, her background seems to be focused on strategic IT planning, so that many of her comments are applicable to other technologies, but she’s done a good job of moving from a generic IT strategy to a mostly BPM-focused strategy. She’s really talking about business architecture in this presentation, where BPM is just one of the methodologies and tools that might be used as part of business architecture — she stated explicitly that enterprise architecture is the context for BPM, a view that I’ve been discussing with my clients for some time. Unfortunately, many EA efforts are really more information architecture groups within IT, and they mostly ignore business architecture and other “soft” parts of the architecture.

There was a question about how to reconcile business analysts in both business and IT reporting areas; unfortunately, I think that she misunderstood this as how to reconcile business analysts in business and system analysts in IT, which is a communication issue rather than an organizational issue. I often see the business analyst title used for people in both IT and business, and my feeling is that business analysts belong in the business, although business process analysts should have at least dotted-line reporting to a BPM center of excellence if one exists. I’d love to hear any comments from readers on what they’ve experienced here with where business (process) analysts report and what works best.

Another question was about the role of the executive sponsor, and she had some good comments on how to manage your executive sponsor: establish a service level agreement with them, where they agree to four hours each week of effort, and agree to a specific timeline for responding to requests for decisions. A recommendation of hers, which would be difficult for a lot of people, is to document in the project reports if the executive sponsor is not meeting their obligations.

2008 02 05 Sandy Kemsley BPM
Gartner BPM Comments (2)

Mapping BPM Events

Coincidentally on the same day that Todd Biske and I start collaborating on the BPM, SOA and EA calendar that you can find on both our sites, I saw this amazing post (linked from the Google Operating System blog) showing how to map a Google calendar’s events on a Google map, with a bit of help from a simple Yahoo Pipe. The results, showing our events calendar, can be found immediately beneath the calendar.

The theory is that this should refresh from the pipe (and hence the calendar itself) every time that you visit the page — or, if you prefer, a link to a larger version of the map directly in Google Maps — although I haven’t tested that out.

If you’re an author on the BPM Google calendar, be sure to fill out the location field so that your event is displayed on the map.

Definitely the most fun that I had all day.

2008 01 29 Sandy Kemsley BPM
SOA Comments (0)

BPM Events calendar gains a new audience

Todd Biske, whose blog I read regularly, announced last week that he was going to publish a Google calendar of BPM, SOA and EA events, I invited him to join the one that I’ve been running for a few months. During the time that I’ve had the calendar active, I’ve added about 10 other authors to the calendar who can add events; these are typically people very active in the industry and have events to contribute. If you want to add an event, you can email to either Todd or me; if you think that you can make an ongoing contribution, then let us know and we’ll add you as an author.

You can view the calendar on my site here, or on Todd’s site here. If you have a blog on a related subject, feel free to embed it on your site as well. Good place to check first if you’re organizing an event and want to make sure that it won’t conflict with competing events.

2008 01 29 Sandy Kemsley BPM
SOA Comments (1)

Metastorm acquires Proforma

Metastorm announced today that they’ve acquired Proforma. Strangely, the Proforma URL already remaps directly to the Metastorm site and the products are already relabelled as “Metastorm ProVision”; most acquired companies keep their own site and brand visible for a while so as to not freak out customers who haven’t heard about the acquisition yet.

I covered the Proforma user conference last year; I’ve always been impressed with their modelling tool since it goes beyond process modelling to full enterprise architecture modelling, and they seem to be moving in the right direction with increasing their browser-based modelling capabilities to allow this to be rolled out to a greater user base within an organization. They’re currently leaders in both the BPA space and the EA modelling space.

There’s still the round-tripping problem, however: I haven’t been briefed on this by either party, but based on my past conversations with Proforma, I’m suspecting that it’s a one-way trip from Proforma’s modelling environment to Metastorm’s process execution environment, since you likely have to tweak the modelled process significantly in order to make it run, and they likely aren’t supporting an extensible interchange format that would allow those changes to stay with the model if it were moved back to the modelling environment. I’m just guessing on this, of course, and would love to hear different. And, although Metastorm was one of the first vendors to offer a free downloadable process modelling tool, I can’t find that on their site any more, so they may be putting all of their process modelling eggs in the ProVision basket.

Metastorm bought CommerceQuest in late 2005 to improve their integration-centric BPM capabilities, and this acquisition rounds out the front end of their product suite — Forrester gave them a black mark in last year’s report for relying too much on third-party software, and this directly addresses that concern. The trick, as with any acquisition, will be how seamlessly that they’re able to integrate Proforma’s products.

2007 08 01 Sandy Kemsley BPA
BPM Comments (14)

BPM Think Tank Day 3: BPM & SOA panel

We’re starting to wind down a bit, and many of the east coast people have taken off already to avoid the red-eye flight home so the audience is getting a bit sparse. Those of us with presentations this afternoon, however, are still here.

First after lunch is a panel on BPM & SOA, and how they complement each other, with Tony  Baer of onStrategies and Brenda Michelson of the SOA Consortium. This is more of the mini-presentation format rather than a true panel, but I promised Brenda that I wouldn’t blame the presenters for that. :)

Tony started out with the “BPM is from Venus, SOA is from Mars” phrase, which we’ve all been bandying about for a while, although he really meant ‘business is from Venus and IT is from Mars). Considering, however, that Venus is the goddess of love (collaboration in its most basic form, perhaps?) and Mars is the god of war (technology shoot-outs and other battle language), that may not be far from the truth.

He addressed the culture issues: both business and IT talk about business processes, but business tends to take a top-down approach versus IT’s bottom-up approach, and business is using BPM to rationalize the business whereas IT is using SOA as the next great way to integrate applications. He sees a process orchestration battleground between BPM and SOA about where to do integration in a process. He also pointed out that BPEL is still at the “checklist” level (that is, it’s on the RFP checklist but not actually used) for most BPM applications, an opinion that I stated here a couple of weeks ago.

Brenda was up next talking about business-driven SOA and the SOA Consortium, and looked at the correlation between an Economist survey of late last year with her personal findings in touring around talking to CIOs and CTOs: the top thing that they state is critical for both revenue generation and cost cutting is the creation of services. One CTO saw BPM, SOA, Lean and Six Sigma all as the same basic thing, namely business strategy and structure, and they need to work together without artificial divisions between them in order to enable a platform for business agility.

Before SOA, business and IT strategy weren’t well aligned and were often developed independently, and the business process became an output of an IT solution rather than driven directly by business requirements. Business and IT need to collaborate on both strategy and architecture, which in turn drives out portfolio planning and delivery of the business solutions. She pointed out that also “enterprise architecture” is currently mostly technology architecture with a bit of business architecture on the side (if you’re lucky), in the future it will become more balanced with equal contributions from business and technical architecture.

Part of what the SOA Consortium is doing is providing guidelines for how the too-technical technology architects can become more valuable enterprise architects, and to break the artificial divide between business and IT. Part of this, I think, is similar to something I posted a year and a half ago, where enterprise architecture is not an IT function, but something that is in a strategic position between business and IT.

We’re off to do the last of the roundtables now, where I’ll be leading one on Enterprise 2.0 and BPM mashups. My notes will be on paper, and I’ll summarize them over here sometime on that overnight flight home tonight.

2007 07 25 Sandy Kemsley BPMThinkTank
SOA Comments (2)

BrainStorm BPM Day 2: Ken Orr

For the first breakout session of the day, I attended Ken Orr’s talk on Business Process Driven Enterprise Architecture. He started out with some observations: improving business processes is essential for enterprises; business architecture is critical; modelling is critical; and business processes are hard to manage in the real world and especially in big organizations. Nothing earth-shattering here, but excellent points.

He made a great analogy by talking about IT levees — fragile yet critical applications and systems where you know that they’re a weak point but just never find the time or money to fix them — and understanding when they’re going to break. Apparently, a year before Hurricane Katrina, there was an exercise that modelled exactly what would happen if a force 4 or 5 hurricane hit New Orleans, but nothing was done; when Katrina hit, the levees failed exactly as modelled. Orr talked about mission critical spreadsheets as being one class of IT levees that are all set up to fail at the wrong time.

He talked about how enterprise architecture is like city planning, where your deliverables are things like a city plan, a zoning plan, a building code and an approved building-materials list. Sticking with the disaster analogies, he talked about how building codes are the result of disasters, and the obvious analogy with software and system disasters is pretty clear.

He covered off their enterprise architecture framework briefly, but used it mostly to discuss how the different layers in a framework interact: in short, technology changes enable business changes, and business changes drive the need for technology changes. He also talked about determining what type of business that you’re in, that is, what business processes are you really doing, so that you can figure out whether or not you should be in those businesses as well as how to improve them. Funnily enough, he really answered part of the question that I asked in the panel in the previous session with respect to getting an end-to-end business process view, but that’s sort of expected from an enterprise architecture person since EA can be a key tool in doing just that. In his terminology, what I’m talking about is a value stream, defined by James Martin in The Great Transition as “…an end-to-end set of activities which collectively create value for a customer.”

Update: I forgot to add “Orr’s rules of modelling”, which he gave after I had shut down my laptop, so were just scribbled on a piece of paper:

  1. It’s more important to be clear than correct. If you’re clearly wrong, someone will correct you. If you’re obscurely correct, you may never know.
  2. It’s not important that your first model is correct, only that your last model is correct.
2007 04 11 Sandy Kemsley BPA
BrainStorm2007 Comments (1)

Gartner Day 2: Daryl Plummer

The second day started with a keynote by Daryl Plummer, BPM/SOA Elixir (unfortunately, I missed the breakfast session with Michele Cantara about the BPMS market, but I ended up in a fascinating discussion about requirements collaboration using wikis with Jason Klemow, and the concept of subscribing to processes with specific attributes in a BPM with Dennis Nickel of Telus).

Daryl Plummer speaking at the Gartner BPM summitPlummer obviously likes to play with the new technology, which I suppose is a prerequisite for his job: he talks about TiVo and Second Life as things that are fast becoming essential parts of culture, although it’s clear that few people in the audience (except maybe me) embrace both the concept of downloading and consuming what I want when I want it, and the importance of online social networks.

He starts with some basic definitions of “service”, especially the relationship between processes and services, to drive home the idea that SOA impact people too, not just systems. He also made an excellent distinction between a model-driven (process-centric) view and a typical programmer view of things: a model-driven view describes what a person does (the business process); a programmer view describes what the system does (the code that attempts to implement that process). After having a discussion earlier about defining processes based on the data values that flow through those processes, when I couldn’t quite elucidate why that wasn’t ultimately the right way to do things, this strikes me as an important distinction.

He summarized the results of Gartner’s 2006 CIO survey (”CIOs are programmers that are passin’ for normal folk”), where the top business trend is improving business processes: there’s a lot of pressure all around to automate processes and improve them along the way, and this is going to happen only with both SOA and BPM. Plummer takes the enterprise architecture view of this, which I really appreciate — business context and functions driving from the top of the architectural view, and services as a way to fulfill the needs of the business. Processes need services to be implemented quickly and effectively, and services aren’t of use unless they are consumed by processes. SOA allows us to build an infrastructure of shared services for ready consumption by processes.

One of the key reasons for SOA and shared services is that legacy apps are still hanging around, in spite of all our efforts to get rid of them. Adding a service layer over the legacy apps allows us to create higher-level services and processes that consume these services without having to know how — or even what platform — to access the data directly on its original platform.

SOA, as Plummer reinforces, is an architectural style: not web services (although web services can be used to implement SOA), not a particular product, but encapsulated functionality accessed through a standardized interface that allows for loose coupling of services and applications. He goes through a checklist of how to know SOA when you see it, although some of the items on his list (such as a centrally managed runtime middleware network) are not, strictly speaking, an essential part of SOA.

Sagrada FamíliaHe continues on with a discussion of event-driven processes (he refers to them as event-driven services in counterpoint to BPM-driven services, which is not necessarily a separation that I agree with). Services, properly implemented, can be combined into event-driven processes rather than structured, pre-defined processes, in order to be able to respond to events that happen in an unexpected order or manner. I did, however, like his view of the “new” application container: UI and navigation via a portal, security and management as part of the network, and logic and data accessed via services from wherever they might exist. Explicit orchestration ties all this together, which provides agility in the process model.

He points out that an SOA is never finished: in fact, it’s designed to never be finished. He uses the analogy of the Sagrada Familia in Barcelona, a cathedral that’s been under construction for more than 100 years now, and continues to change as it is built. He covers off some things about development techniques to be used when developing services within an SOA infrastructure, and highlights the business service repository as a centrepiece for BPM’s use of SOA.

His final recommendation is that the critical path to competitive business advantage goes through SOA and BPM: you need to use SOA as the underlying mechanism, BPM as the methodology for tying things together in order to get the business process improvement that’s required to differentiate your organization in the marketplace.

2007 02 27 Sandy Kemsley BPM
Gartner BPM
SOA Comments (0)

ProcessWorld Day 1: Services industry breakout with Todd Lohr of Zurich North America

The second customer breakout session was Todd Lohr of Zurich North America, who discussed various process modelling initiatives within Zurich. They’ve expended a ton of effort on detailed as-is process mapping in order to drive process improvement, and it appears to have paid off even before implementing process automation.

They had some interesting discoveries: 4 out of 5 top activities (by time spent) did not add value to the underwriting process; many activities done by an underwriter could be done by an underwriting assistant; the start time of certain processes was causing unnecessary delays due to timing or unavailability of staff (underwriters work late, whereas the assistants work 7-3, so all assistant-level work after 3pm was done by an underwriter); and bad insurance applications (e.g., missing data) can be found and aborted earlier in the process through the appropriate triage. Having worked with a lot of insurance customers, I don’t find any of these surprising, but I was impressed by the thoroughness of their as-is modelling and how they were able to exploit it to improve processes, technology and organizational structure.

They use ARIS to create the future state models and help the transition from the as-is to the to-be processes. They see it as a tool for training, simulating and communicating, as well as determine staffing and economic value of processes.

Future plans include integration of business rules, and getting some of these processes automated in a BPMS.

2007 02 07 Sandy Kemsley ARISProcessWorld
BPA Comments (0)

ProcessWorld Day 1: Services industry breakout with Marc Kase of SAIC

After lunch, I attended a couple of ARIS customer breakouts, the first of which was Marc Kase of SAIC. I won’t give a lot of detail about their business processes, since I’m not sure how much that they really want to share outside the conference, but there were some great points and lessons learned that are more generic.

One of the first stats that hit me on the SAIC case is that they moved from 700 to 70 (it may have been 78 — I was in the back and the print on the slide was small) job roles as part of their process modelling efforts, which is an incredible success story.

They’ve focussed on building a business architecture, with process models created for projects stored in local repositories, then promoted to a central enterprise architecture repository at certain milestones. From this, they’ve been able to see a number of benefits:

  • Context, e.g., which systems use which data
  • Documentation that allows requirements and design to be traced back to business processes
  • Standards enforcement
  • Ability to cascade changes across models
  • Web publication of process and architecture content
  • Strengthened ties between IT and functional process owners

They also learned a few lessons, such as some of the difficulties in enforcing change control in moving from a single project to a portfolio of projects, and some practical issues around setting tightly-controlled standards in order to reduce the user learning curve; in fact, with the appropriate filters and standards in place, their users find ARIS “much easier to use than Visio”.

They have a number of plans for 2007, including simulation, integration with a number of other systems including their BPMS, building out the complete enterprise business architecture, and using “system of systems engineering” to track interdependencies between projects.

2007 02 07 Sandy Kemsley ARISProcessWorld
BPA Comments (0)

The Modelling-to-BPM cycle

I attended a webinar last week about Proforma and Workpoint, and I have to say that the “for more information” slide at the end of the presentation is the best one that I’ve ever seen in all my years of corporate presentations. Dan, that may not be your picture on the slide, but kudos. Update: screenshot of the slide removed at the behest of Workpoint, who claim that the slide that I saw on the screen didn’t exist in their slide deck.

The topic of the webinar was Bringing BPM and BPA Together (replay available on Feb 7th), and it focussed on how you can do your complex modelling, analysis and simulation in Proforma’s ProVision, then export/import your way over to Workpoint’s BPMS for execution.

I found this particularly interesting because it highlights the divide between the BPMS vendors who (attempt to) provide everything to do with process under their own banner, and those that rely on partner relationships through a best-of-breed approach.

At the Proforma user conference last year, one of the speakers asked the audience how many of them were exporting their process models to a BPMS for execution. Out of about 150 people, only a couple of hands went up, which surprised me (as I discussed in my post about that presentation, Is Anyone Executing Those Processes?). ProVision doesn’t yet support XPDL, and many of the BPM vendors are just getting onboard with XPDL themselves so haven’t been ready to accept process models from a modelling tool, but there has been integration done between ProVision and some number of BPMS using their Proforma’s XML-based interchange format, CIF. Presuming that many of the companies using ProVision are also using a BPMS, this seems to imply that someone is taking the process models created in ProVision and recreating them manually in the BPMS. So why is this happening? Is it a technology disconnect (BPA and BPM can’t exchange models) or a human disconnect (modellers/architects and BPM jockeys don’t exchange models)?

Proforma and Workpoint are obviously trying to buck this trend by promoting how much better things can be when you use the strengths of both of their products. I’m a fan of this approach if you’re using a full enterprise architecture modeller like ProVision as opposed to a process-only modeller, since you can do all of your EA models in it and your process models become part of the larger picture. I’m headed off to the ARIS ProcessWorld conference later this week, so I may discover more of the advantages of a process-only modeller, too.

It makes sense for smaller BPMS vendors like Workpoint (whose product I am completely unfamiliar with, except for last week’s webinar) to leverage relationships with modelling vendors like Proforma to fill in the gaps in their product, although larger vendors who are side-slipping into the BPM space are also going that gap-filling route, such as we see with the Oracle-IDS Scheer relationship.

At the other end of the spectrum are the mainstream BPMS vendors, particularly those categorized as “suites” or “pure-play” (depending on which version of which analyst report that you read), which include modelling, simulation and all manner of process analysis as part of their product. Although you can’t escape having a process modeller (and likely simulation) in your BPMS in order to be considered a serious player, I’m still left with the feeling that there’s a lot to be gained by using a tool that is both more specialized in process modelling — in order to be able to capture non-automated steps, for example — and provides a broader enterprise architecture modelling scope.

2007 02 05 Sandy Kemsley BPA
BPM Comments (0)

Strategic Planning with Enterprise Architecture

Laura Six-Stallings from QAD gave a presentation on how they are using enterprise architecture for strategic corporate planning, which absolutely fascinated me since most EA projects that I’ve been involved in have been focussed at much lower levels. She used some wonderfully funny war analogies, going so far to call ProVision a “weapon of mass depiction”, which takes the prize for the best quote of the day.

Since I had been online earlier and determined that her presentation was not available on the Proforma website, I ended up taking a lot of notes, so have a better memory of this presentation than some of the others. I didn’t see anything in the presentation that would have made it particularly proprietary, since she didn’t show their actual strategic planning results, just talked about the methodology for achieving it, but some companies are more paranoid than others.

They started their EA initiative in 2002 with about a dozen business and technology architects, and started using ProVision just last year to implement the Zachman framework. They have a very holistic view of EA, from corporate strategy on down, and they hit their strategic planning process as an early target for EA. Like many organizations, they did their strategic planning in PowerPoint and Word; with over 60 pages of slides and 280 pages of backup documentation, it was a time-consuming and error-prone process to create it in the first place, then to map that onto the more concrete goals of the organization. By implementing EA and ProVision, they were looking to improve the entire process, but also gain some clarity of alignment between strategy, business and technology, and some clarity of ownership over processes and strategies.

She made several turns of phrase that elicited a knowing laugh from the audience — IKIWISI [I Know It When I See It] requirements; As-Was and Could-Be models — but really brought home the challenges that they had to overcome, and the wins that they are expecting as this process rolls out. The biggest issues weren’t surprising: a perception of complexity, based in part of the limited ProVision expertise within QAD, and the cultural shift required to embrace a new way of modelling their strategic plans. However, they now have a long-term strategic plan based roughly on balanced scorecard objectives, and have a whole list of anticipated benefits:

  • Common taxonomy and semantics
  • A holistic multi-dimensional view of enterprise activities
  • Enforced alignment to the strategic plan model
  • Exposure of dependencies, relationships, impacts and conflicts
  • Improved communication and acceptance of the strategic plan
  • Improved priority management
  • Common processes
  • Effective reporting and analysis
  • Improved collaboration

Quite lofty goals, but achievable given the level that they’re attacking with EA. What I took away from this, and from other conversations that I had during the two days, is that to many people, “EA” really translates to IT architecture, but not at QAD.

2006 10 16 Sandy Kemsley ProformaVision2006 Comments (0)

Enterprise Architecture in pharmaceuticals

It was Craig Confoy’s presentation on Johnson & Johnson Pharma where I really started to get interested in the issue of where EA sits in the enterprise. Although the “E” in EA stands for “Enterprise”, it seems that most organizations, and J&J is no exception, start out with EA in the IT infrastructure group somewhere. Like many large conglomerates, they had a bit of a mess with five pharmaceutical R&D companies (out of J&J’s 200-odd companies), each with its own IT department supporting 14 different functional units per company, and little alignment between the company functions. Since EA was in IT infrastructure, anything in the business layers of EA, such as business modelling, was done on a project-by-project basis and not shared between business units or companies.

Sound familiar? Almost every large company that I deal with has the same issues: some real architecture going on at the lower infrastructure levels, but practically none at the business levels.

About 5 years ago, J&J Pharma decided to do something about it, and created a business architecture group. There were a few stumbles along the way, such as the use of a (seemingly inappropriate) CASE tool that resulted in business process documentation that stretched over 42 feet at 8pt font — unusable and unsustainable — before they started using Proforma.

One of their models that I really liked was an enterprise data model that could be overlaid with departmental ownership, so that you can easily see how changing any part of the model would impact which departments. I think that this is one of the basics required by any large organization, but often not used; instead, companies tend to replicate data on a per-department basis since they don’t have any enterprise data models that would tell them who is using what data.

This was one customer presentation that showed some clear ROI of using the Proforma tools: they found that systems could be implemented 30% faster (a huge advantage in pharmaceuticals), that the modelling process identifies system integration points and allows them to create standard EAI models for reuse, and that the data models helped meet their regulatory requirements more easily.

2006 10 16 Sandy Kemsley BPA
ProformaVision2006 Comments (0)