EA – Page 7 – Column 2

Gartner podcast on EA leaders

A good 9-minute podcast from Gartner on the role of enterprise architecture leaders, featuring Robert Handler, one of their research VPs. He spends some time discussing how an EA role is more than just IT:

“It’s become a truly leadership role, one that involves strong communication skills and fundamentally bilingual capabilities, being able to speak both business and IT.”

Handler mentions that the EA role often includes aspects of process optimization now. He also says that although EA’s have moved up from reporting a couple of levels below the CIO to reporting directly to the CIO, that they should really be reporting to the CEO — something that I’ve posted about previously. Lots of good stuff on who the enterprise architect should be forming strong relationships with, in order to help foster architectural alignment throughout the organization.

Update: there’s also an EA-related podcast from Macehiter Ward-Dutton, a UK-based consultancy. The first part is unrelated industry news analysis, but there’s some EA bits based on a discussion that Neil Macehiter had (offline) with James McGovern starting at the 23-minute mark. Apparently, they’ll be having McGovern on the podcast later this month.

EA and process modelling

I saw this post by John Wu on the myth of business process-centric enterprise definition (via Lucas Rodríguez Cervera), and I find it hard to see how anyone gets away with “defining the enterprise based on business process modeling in EA”. Business process modelling has a place in enterprise architecture, but it’s just one of many tools/techniques for creating the necessary EA artifacts. For example, if you’re a Zachman follower, you’ll find business models only in row 2 (business model/owner context), and something that could be described as a business process model really only in columns 2 (function) and 4 (people) of that row: two artifacts out of 30.

Wu proposes defining the enterprise from the aspect of mission (why), function (how), information (what), stakeholders (who), stakeholder location (where) and stakeholder demand (when) rather than the exhausted [sic] enumeration of business process modeling, which really seems just to be advocating an EA approach to defining the enterprise. And if you’re an enterprise architect, regardless of the framework that you use, you already know that business process models are just one aspect of that definition.

It’s important to understand business processes as part of understanding the enterprise, but I don’t agree with Wu’s statement that most EA projects use business process modelling as their primary understanding of the business, or that EA is just second-generation BPR.

Customers that I’d like to fire

I’ve had two “inconsiderate customer” incidents this week; actually, both are customers who I’ve done quite a bit of work for in the past but have been inactive for some time.

With customer #1, I contracted in as their business and application architect for several months; even though they didn’t really get what enterprise architecture is all about, I spent most of a year trying to do some internal education on the necessity for EA to help sort out the legacy linguine that was rampant in their organization, as well as the lack of business-IT alignment. A while after leaving, on April 29th 2005 to be exact, I dropped my key contact there an email about the (then) new report from BPTrends on EA tools, saying the following:

…there’s a new report out from BPTrends on enterprise architecture that you can download for free. I gave it a quick review on my business blog, which includes a link to the report. Although the product information in the report is nothing that you can’t get from the vendor’s sites, the first 25 or so pages are a great overview of enterprise architecture, process modelling and simulation tools that provide good background material if you’re ever promoting a related project. I did an earlier post on their report on BPM suites that you might also find interesting.

Usually this type of email at least gets a “thanks”, or “hey, it’s been a while, let’s meet for coffee”, but nothing came back from this. No big deal, customer #1 is a busy person. Then on Tuesday of this week, 340 days after my original email, it arrives:

With customer #2, I did the architecture and design of their original BPM system, and they now need some analysis and design assistance to further increase efficiencies (which presumably would more than pay for my engagement there). Their internal IT architect contacted me in November 2005, we chatted on the phone and by email, then he connected me with the project manager. Long pauses in the conversation ensued, punctuated by several emails and voice mails from me to the PM. Responses took as long as six weeks, or never came at all. Finally, they made a request to have me fly to their site this coming week — the week leading up to Easter, with Friday a holiday here in Canada, and Saturday being when 13 members of my family will be descending on my home for Easter dinner. That, of course, is my problem, so I said yes. Turns out that no one had the funding approved, however, so I received an email two weeks ago saying that the trip was off. I immediately responded with some suggestions on how to restructure the project to reduce the funding issues while still providing value. Their response? Silence, so far.

The thing that frustrates me is that I’m not an unknown salesperson cold-calling these people, I’m a geeky engineer type who worked on site as part of the in-house team with both of these customers for several months and did significant amounts of work that were well-received. Are they just snowed under with the amount of email that they receive, and ignoring all of their business contacts equally, even if they were the one to initiate the conversation? Or, because I’m a contractor/consultant, don’t they consider it worth their time to reply to my email (or even open it for almost a year)? At least I’m pretty sure that they’re not reading this blog entry…

Gartner BPM summit day 2: Bill Rosser

I finished up Tuesday at the conference with Bill Rosser’s “Creating a Business Architecture”. I found his enterprise architecture models to be a bit inconsistent: at one point, he includes application architecture in information architecture; later, he splits them out as most of us would tend to do. He did make a great point about architecture up front: architecture is not creating the design, it’s creating the environment/boundary/envelope in which the design can be created. Since many people don’t make the distinction between architecture and design (or even, in some extreme cases, architecture and coding), this was valuable as an explicit statement.

What I did find about Rosser’s talk, like all the other non-BPM “special interest” sessions that I attended (Six Sigma, business rules), is that he failed to make an adequate linkage back to BPM in the presentation. I’ve given presentations on enterprise architecture and BPM in the past, (as well as ones that involve Six Sigma and business rules tied to BPM) and it’s very easy to make a strong link between them, so I consider the lack of tie-in to BPM a critical failing of Rosser’s presentation.

Gartner on BPA for 2006

Gartner has released their Magic Quadrant for business process analysis, and the first big news is that they’ve updated the style of the graphics: rounded corners, one-sided arrows and –wait for it — orange dots!

Seriously, though, this is a good report and comparision of the primary tools used for modelling and analyzing your business processes, whether or not you’re going to automate some of those processes using BPM. However, it’s the linkage between BPA and BPM that is really driving the BPA marketplace, including the whole round-tripping process that allows BAM results to be fed back into the BPA tool for further analysis and optimization.

Many of the BPM vendors have BPA included in their product; in fact, Gartner makes a note that they dropped FileNet from this report since their BPA is so deeply embedded that it’s not sold as a separate product, but they’ve added other BPM vendors such as Fuego (now BEA) and Savvion, although they languish in the lower left corner. In other words, you’d use their BPA if you were using their BPM, but you’re not going to buy it as a standalone BPA tool, as I’ve discussed previously. For that, you look to the big guns in the top right of the quadrant, such as IDS Scheer and Proforma. Although IDS Scheer focusses purely on process modelling, Proforma, Telelogic (formerly Popkin) and a few others go far beyond that to full enterprise architecture modelling, of which process modelling is an important but small part. I haven’t written much about EA lately, but it’s definitely a topic very near and dear to my heart.

I find it interesting that Gartner has chosen the vendors for this MQ in such a way that they are only in the “leaders” or “niche players” quadrants: not a one in the “visionaries” or “challengers” quadrants. They give an explanation for why this happened in the full report, but I feel that the comparison chart is less useful for tracking future trends without the visionaries and challengers. Personally, I would have put Microsoft (Visio in the BPA product under review) a bit more to the left into the challengers’ quadrant, since it’s not clear to me that their vision for making Visio a full BPA offering is particularly complete.

Last year, I posted about BPTrends‘ report on enterprise architecture, process modelling and simulation tools, which includes many of those in Gartner’s upper right quadrant. The vendors paid to be part of the BPTrends report, so it’s not exactly indepedent analysis, but it includes some good background material on the market (and it’s free).

Webinar: Taking BPM to another level

I’ve just finished listening to an ebizQ webinar How to Take BPM to Another Level in Your Organization, featuring Jim Sinur from Gartner. webMethods is the sponsor, so Susan Ganeshan, their VP of Product Development, is also on the line.

Sinur made a quick plug for the upcoming overpriced Gartner BPM summit, but then dug into some interesting material. Much of it was a duplicate of what I had seen presented by Michael Melenovsky in Toronto a few weeks ago — such as the comparison between a functionally-driven and process-driven enterprise, and the set of practices required around BPM — but it was good to see it again since I still haven’t received a set of slides from the Toronto seminar so had to rely on my rough notes. I liked the slide on the roles and responsibilities of business and IT, especially the centre column showing the shared responsibilities:

Process deployment

Process execution and performance

Business and process rules analysis and management

Operational procedures including version level control

Creation of process, rules, and events repository

Detailed process design

Training and education

Event analysis and management

This lines up with what I’m seeing with my customers, as IT relinquishes more control to the business, and the business starts to step up to the challenge in order to ensure that what gets implemented is actually what they need. I believe that the business still needs to be more proactive in this area: in the large financial institutions that I mainly work with, many parts of the business have become completely passive with respect to new technology, and just accept (while complaining) whatever is given them. I’m not in favour of giving over design control to the business, but they definitely need to be involved in this list of activities if the BPM project is going to hit the ground running.

I also liked the slide on what’s happening with rules and BPM in the context of policy-managed applications:

This is a very enterprise architecture-like view of the process, where you see the business policies at the top, the resultant rules immediately below that, then the linkages from the rules to the data and services at the bottom, which are in turn plugged into specific steps of the process. Making these linkages is what ultimately provides business agility, since it allows you to see what parts of the technology will be impacted by a change in a policy, or vice versa. There really needs to be more enterprise architecture modelling going on as part of most organizations, but particularly as it related to process orchestration and BPM in general.

At the 22 minute mark, Sinur returned to another 2 minutes of shameless plugging for the conference. Considering that we were just warming up for the “real” vendor to start plugging their product, the commercial content of this webinar was a bit high.

Although webMethods supposedly entered the BPM market back in 2001 on their acquisition of IntelliFrame, I’m not seeing them on any BPM radar screens — they’re really considered more of an integration suite. Ganeshan really should have practiced reading her script before she read it on the air, too, although she was much better at the Q&A. Except for the remark about how they don’t do BPMN because their customers really like webMethods’ “richer” proprietary interface instead (as if they have a choice).

At the end, the moderator showed the results of the survey question that she had posed near the beginning of the webinar. No big surprises here, although interesting to note that all of the drivers (except for document compliance) are becoming equally important to people. The trend that I’m seeing is that the goal of improving operational efficiency (shown on this survey as “reduce operational costs” and “reduce process errors”) are being taken for granted: everyone expects that will be the result of implementing BPM, so it’s not considered the main business driver. Instead, process visibility and process orchestration are moving to the forefront, which in turn drive the agility that allows an organization to bring its products and services to market faster.

ebizQ is using some new webinar software lately (or maybe a new version) which has some nice new features. It allows you to download the presentation at any time (other webinar providers could learn a HUGE lesson from that), zoom on the slides, and other features from the previous version, but now also shows a list of upcoming webinars in the sidebar and allows you to pop up a list of the attendees (first name and company only). Unfortunately, I had some major connectivity problems that resulted in a five minute gap right at the beginning of the Q&A, so I’ll have to go back to the replay and check it out. Fortunately, they publish the replays very quickly after the event, using the original URL, another good lesson for other webinar providers.

Gartner’s podcasting!

It’s the last company that I expected to be giving it away (for now), but Gartner is publishing podcasts as Gartner Voice. They cover a wide variety of topics so I won’t be listening to them all, but enough of them look interesting for me to add this to my iTunes feed. I also like that they’re short, 10-15 minutes each rather than the hour-long behemoths from other sites that I never find the time to listen to.

There’s an one on BPM as a business catalyst that has some comments on how an organization’s justification for BPM changes from cost savings to agility (both business and IT) as they implement more BPM projects, and also some insights on the coming market convergence.

I’ll also be checking out the one on articulating enterprise architecture in business terms.

Business-driven EA

A thought-provoking post from Brenda Michelson on the Business-Driven Enteprise Architect, including some steps for the CIO to take in order to ensure EA success, such as:

Make Room at the Table for Architecture Leadership. The architecture leader must have a seat at the CIO’s table in IT leadership and business leadership settings. The architecture leader, particularly one with an architecture background, will listen and contribute to the discussions with an enterprise architecture perspective. Don’t filter his/her information through a leader with a non-architecture focus.

Changing business models = changing business processes

I read this post by Alex Osterwalder on the external forces that impact an organization’s business model — technological change, competitive forces, customer demand, social environment, and legal environment — which in turn has me thinking about how these business model changes impact business processes.

This is precisely why I look at issues of enterprise architecture and BPM together, even when a client has specifically engaged me for a BPM initiative. In a perfect world, the following occurs:

A business model changes based on internal or external factors
One or more business processes have to change to respond to the changing business model
The business processes are implemented using a BPMS
EA provides the linkages between the business model and the information systems (including the BPMS) so that the right changes can be made to the process in order to respond to the changing business model

Unfortunately, there’s a lot of roadblocks to establishing what I feel is a fairly obvious requirement for remaining competitive in the face of changing business models:

Impact analysis: many organizations don’t document their business models (by this, I mean their high-level company business models, not their departmental business processes and procedures), or don’t make adequate links from their “strategic planning” sessions to all the layers below that have to implement those models and plans. Because of this, there is no clear link between the change to a business model, the change to an underlying business process, and the change to the supporting information systems.
Automation: many organizations are still using manual processes and decision-making for well-understood business processes. For example, some insurance companies process all of their claims manually; others have greatly improved productivity by using automated adjudication systems that pass only the more complex claims to a human claims adjudicator. Although the former may understand that a BPMS can help their business, they see it primarily as a way of paving the cowpaths so as to provide faster movement of information between the same old human decision-making processes, rather than a tool for automating some of the steps and — with the addition of business rules — removing some of the human decision-making.
Agility: some organizations that implement a BPMS end up with automated business processes that are frozen in time due to an excessive amount of customization around the implementation. Although they’ve achieved automation (albeit, optimized for a point in time usually about a year prior to implementation), they’ve completely lost agility due to the complexity of changing the BPMS by creating a legacy business process.

These issues, which I often uncover during a client assignment, require more than just a few tweaks to their BPMS: they require that both EA and business rules be brought into consideration in order to provide the business agility that the client is expecting.

To begin with, EA can help to create the necessary models and the linkages between the layers to allow the impact of a business model change to be reflected in the business processes and the supporting information systems. If you can’t do impact analysis, then you don’t have any type of reliable business agility since you won’t understand all of the impacts that a change to any part of the organization might have on other parts.

BRMS are an essential facilitator to business agility. First, because they put the business rules in the hands of the business (or at least in a form that’s understood by the business), so that there’s much less latency in the process of changing business rules. Secondly, if a shared repository of business rules is implemented across the organization, then a change to a business rule can be immediately be reflected in every process and system that accesses it, from the next call handled by a call centre operator accessing a CRM, to work in progress in a BPMS.

Of course, I see BPMS as a given for business agility: it lets you automate business processes while still involving human intelligence at the points required in the process; integrate business rules for decision-making; and more easily make changes to the business process with less user retraining. There are good and bad ways to implement a BPMS (as with any system), and care must be taken to integrate other tools (such as BRMS or BI) where appropriate, rather than go down the path of excessive customization which can hinder agility.

The bottom line is that although a BPMS can be a huge contributor to business agility, it can’t do it alone: you need some amount of EA in order to understand what you’re supposed to be doing with that BPMS (that’s the business-IT alignment that everyone talks about), and you need some other tools like BRMS to keep things agile through a minimum of customization.

Integrating Information into the Process

How much information and how it is used is a fundamental issue that I always deal with when designing processes: the usual tendency is to put too much information into the process itself (typically because the line-of-business system is so ugly that no one wants to deal with it directly), but that over-replication of data causes problems with synchronization and potentially performance. I’m a big fan of keeping the data in a process to the minimum as long as those other systems can be accessed in some way, and replicating data into the process for three reasons only:

Data elements that link this process instance to other systems, e.g., an account number. If you want other information about the account, I’d recommend that it come from the system of record, not be replicated into the BPM system.
Data elements that are passed or displayed to the agent executing a specific step in the process flow, whether a human user or another process/system, that allow them to execute the task at hand. This may be the same information as in the previous case, such as an account number, but may also be instructions such as “call the customer for the missing data on their application form”.
Data elements that are used to control process flow. For example, if transactions of greater than $1000 in value follow one path in the process flow, and those less than that follow another path, then you need to have a “transaction value” data element in your process.

As Value Wizard points out in Process/information integration, too much information can be just as bad as too little, and can lead to delays and inefficiences while a human operator sorts through a mass of data to find the one piece that they need to execute the task at hand. He points out that we need to be mapping information architecture right along with the process and business architecture, and points out the value of an enterprise architect in ensuring that the information (data) architecture is aligned with everything else.