EA – Page 5 – Column 2

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):

Identify the roles in a process.
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.
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.
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.
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.

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.

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.

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.

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.

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.

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.

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.

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:

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.
It’s not important that your first model is correct, only that your last model is correct.

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).

Plummer 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.

He 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.