(Note: I’ve added an addendum to this post)
It has been many years that we have lived with the concept of technical debt. Martin Fowler did a good job of describing the concept in a 2003 article on his wiki. Basically, the idea is that you can make a quick-and-dirty change to software. You will have to spend time to fix that software later. That additional time is like an interest payment on debt that you incur when you made the change. Fixing the code to make it more elegant and clean “pays down the debt” so that future changes cost less to make.
I’d like my fellow practitioners to consider joining me in extending this idea to the enterprise.
Organizations change, and sometimes the changes have to be made quickly. Processes that are implemented “quick and dirty” may have poorly defined roles, overlapping responsibilities, and duplicate accountabilities. It may work, and it may be necessary to hit a deadline. However, these “dirty” processes have the same problem that dirty code does – it costs more later to fix them.
In a sense, partial process or accountability “fixes” in an organization create “enterprise architecture debt” or “EA debt.” We run into it all the time in organizations. Here are some examples that I’ve personally seen:
- One team is responsible for checking the quality of all manufactured products and making sure that they get to distributors. However, products that are custom developed have their own quality check and distribution function. Effectively, two different teams duplicate a couple of functions. This could be simplified, and doing so would likely reduce costs and improve consistency in quality checks.
- The marketing team uses data mining techniques to identify potential customers (prospects) and enters them into a system along with attributes like segment, predicted value, and targeting within specific marketing programs. When a new customer reaches out to actually purchase a product, however, the customer record is created in a CRM system that is not linked to the marketing record. Consistently linked customer information could provide valuable information about the effectiveness of marketing programs as well as enriching customer information for the sale of service and ongoing sales.
- An outpatient specialty radiology department in a Hospital requires patients to be registered separately from other hospital services in order for patients to be handled. For most patients, this is not a problem. However, for patients within the hospital, the separate registration requirement creates opportunities for errors as information is hand-transcribed from one system to another.
- A retailer sets up an e-commerce division to sell their wares online. However, inventory and warehousing the new e-commerce site is not integrated into existing store systems. The ecommerce “store” is treated as another physical store. This works, but any attempt to allow customers to purchase online and pick up at a store become problematic because the retailer has no way to handle purchases made in one store to be fulfilled by another.
These, and a thousand more situations, are the result of “partial” or “messy” implementation of organizational changes. They are a form of “EA debt” because any change to the organization that hits these capabilities will be more expensive to change in the future as complexity slows down the organization. In effect, EA debt is like taking a Lego set and gluing the pieces together. The parts will remain just as they are, but the will be very difficult to change in the future if something needs to change. (Apologies to “The Lego Movie” for the metaphor).
Why call this “EA debt?” Because it is not a financial term. It is nearly impossible to accurately measure all of the EA debt in an organization. It is, however, fairly straight forward to measure monetary debt. So we have to be careful not to use terms like “enterprise debt” or “organizational debt” as these may be confused with general accounting concepts. Just as technology teams sometimes twist the concept of an “asset” to apply to an information system, Enterprise architects are using the metaphor of debt to refer to one of the root causes of difficulty in making organizational change.
Addendum: I guess I shouldn’t be surprised that this idea is not novel. It’s fairly self-evident. It was my mistake that I didn’t go looking for other references to the idea before writing the above post. Laziness. No excuse. While the concept of technical debt does in fact trace back to Ward Cunningham (inventor of the Wiki), as discussed by Martin Fowler in the referenced blog post, the application of that concept was first applied to EA in 2008 in the Pragmatic EA Framework, and is part of the current version as well. I’d give a link to that presentation if I could but the best I’m able to do at this time is a general link to PEAF at http://www.pragmaticea.com. Kevin directly responded below with links into his material . It is no disgrace to be in the shadow of Kevin Smith (author of PEAF). It is an error, however, to appear to originate the idea. For that, my apologies.
In the world of Enterprise Architecture, we are still creating “shared” understanding of how to tell our stakeholders what we do. There is no consistency in our diagrams or our descriptions just yet. This post will discuss the different ways we present the value stream of Enterprise Architecture and will attempt to select a particular viewpoint that can be useful for the majority of situations.
First, let’s address the most commonly shared representation: TOGAF. The TOGAF ADM model illustrates a sequence of activities that starts with a preliminary phase and works its way through each of the levels of architecture. Basically, TOGAF illustrates a straight-through process from phase A through phase H to develop and use architecture.
First off, I’m no huge fan of this illustration. I always wondered how you get to an architectural vision prior to considering the architecture of the business. Also, the notion of a center point focused around requirements management feels weirdly tactical. At the level of an Enterprise Architect, I’m dealing with strategies and measures of success. At the level of a technical architecture, the word “requirements” has an altogether different meaning. Grouping together the notion of “strategic needs” with “technical requirements” may make sense to a technologist, but I don’t know a single business stakeholder of EA that would agree with grouping those two rather distinct things.
Who is our audience?
These observations bring me to my first key consideration: If we want to communicate the value stream of Enterprise Architecture, we first should consider the audience, “who are we communicating to?” If we are communicating to a stakeholder of EA, we should show them the bits of EA that are relevant to them, and we should not show them the bits that are not.
It is not cynical to gloss over the complex bits of EA when talking to a business stakeholder… it is practical. In fact, we do it all the time. If you buy cable TV services, a person from the cable company may come to your house and install a coax cable to your home. He will mess around with a cable box for a few minutes, and then, if you are lucky, he will show you how to do simple things like changing channels and recording your favorite shows. Then, he’s off. He does NOT spend an hour describing the various technical aspects of signal transmission and digital carrier signals. Why should he? You don’t care. You want to watch TV, not get a degree in electrical engineering. And the same applies to EA.
Secondly, if we want to communicate EA, let’s recognize that different people interact with Enterprise Architecture in different ways. Business stakeholders will interact with Enterprise Architecture to ensure that their strategies are being executed effectively, with minimal interference, and producing a result that considers things like security, cost of ownership, and the ability to cope with rapid changes in the marketplace.
- We have to care who we are speaking to, and we have to reflect the things that they care about.
- We have to show them the details that matter to them and obscure the details that don’t.
- We should illustrate the activities in the context of the processes that they understand, and not at a conceptual level that may be difficult to relate to their daily experience.
The ADM from TOGAF is an odd bird, because it attempts to be all things to all people. It represents EA in a way that every stakeholder can use, but honestly, no stakeholder can use it. It is not wrong. Far from it. But it is not useful because it violates every single one of the rules above. The ADM reflects the EA viewpoint, but not the viewpoint of the customers of EA at a level that they can grasp, understand, and most importantly, use. So let’s keep the ADM in our court, and create a view of the EA process that is relevant to our stakeholders.
So who are our stakeholders? For the sake of this post, I’m going to select one set of stakeholders and ignore the rest. Is that correct? Nope, but it is practical for a blog post. What this means is that the rest of this post produces an answer of the “right” representation only for one class of stakeholders… another representation would likely be needed for different people. That is the nature of EA. Let’s not fret it.
There is a widely held view in Enterprise Architecture that an EA must be technically savvy in order to be effective. There are certainly business architects who are quite effective who are not technologists, but in order to move UP to the notion of an EA (which includes business architecture, information architecture, solution or application architecture, AND technology architecture), you would need to be technically capable.
I won’t belabor the point about whether it is correct to view Business Architecture as a subset of Enterprise Architecture. It is the wildly predominant view. (A poll that I put on LinkedIn that asked this question found that well over 80% of EA respondents agree that EA generally includes every aspect of business architecture. That’s pretty overwhelming.)
That said, our biggest struggles in EA rarely involve conversations with other architects. While there may be a great deal of confusion, there is rarely a lack of buy-in for architecture among architects, or even technologists. Our key challenge, when it comes to communication, comes when we are talking to non-technologists. In other words, the proverbial “business” stakeholders of EA. (Please don’t flame me about whether IT is part of the business or not. That is a useful conversation, but it is outside the scope of this post).
Therefore, for the rest of this post, I will focus on the non-technology stakeholders of Enterprise Architecture. These are people whose chief concerns are not technical concerns. We could say that they care about financial performance, role clarity, cycle time, cost effectiveness, market position, revenue growth, opportunity costs, business drivers, and many other factors outside the realm of technology concerns. People in this category include senior business leaders (CEO, COO, CFO, CIO, CMO, etc), as well as business unit leaders (General Managers, Sales Division Leaders, Product Development and Marketing, Customer Service, Online Services, etc).
In order to communicate directly and well to these folks, lets recognize that they don’t care about the aspects of architecture that are technology focused. While the WANT good technology, and will BENEFIT from good technology, they will assume that the technology issues can be handled effectively without bothering them with details. To refer to our previous metaphor, they want the cable compa
ny to handle the technology, so that they can deal with changing channels.
So, let’s take the ADM, and trim out the stuff that non technologists rely on, but don’t need to have a conversation about. They assume it is there. That includes the preliminary stage, as well as architectural vision, requirements management, information systems architecture, technology architecture, and architecture change management.
The ADM now looks a bit different. In fact, we can put it in a single row with a looping arrow. Note that, in TOGAF, the Business architecture phase includes both current state assessment and future state modeling.
Representing the processes of the non-technical stakeholder
We have removed the confusing bits from the view of the non-technical stakeholder, but it is tough to say that we are at the point where we are relevant. After all, the non technical stakeholder has a business process that he uses when working with changes to his or her business. We are not representing that process.
The process, frequently described in dozens of bits of EA literature, starts with an understanding of the current situation within the business. Then, when the business creates a strategy, we bring these two bits of information together (current state and strategy) to create a vision for the future. This is the order that the non technical stakeholder may recognize… not the generalized view of the ADM. So it is time to break apart and rearrange the bits a little bit. I will now step away from the “crop circles” representation since it is so far out of the experience of people who describe business processes.
In this view, we can begin to see the steps that an Enterprise Architect would perform that are visible to a non-technical stakeholder. Just for the sake of clarity, this doesn’t mean that the technical steps are absent… it just means that our technical efforts don’t have to be paraded around in front of our non-technical stakeholders.
Note that I relabeled the ADM steps.
- Business Architecture becomes Current State Evaluation, and Strategy Development
- Opportunities and Solutions becomes Future State Modeling
- Migration Planning becomes Roadmap Development
- Implementation Governance becomes two things: Funding and Initiation (the Project Portfolio Management aspects) and Oversight and Governance (the governance of ongoing activities).
- Architecture Vision is cut down to only the elements relevant to the non-technical stakeholders: the evaluation of the current state of the enterprise.
Let me point out that the TOGAF process assumes a different order of activities than the diagram above. From the standpoint of the stakeholder, this is what makes sense, regardless of how TOGAF describes the stages. This is why I’m no big fan of TOGAF as a methodology. It doesn’t reflect reality. On the other hand, the elements above are fairly well understood.
Also note that I’m not saying that the substitutions listed above are equivalent. In fact, I’d argue violently that Business Architecture is far more than Current state evaluation and Strategy Development. However, from the viewpoint of the non-architect, business architecture is a process that is involved with the development of business models (current and future), and that’s about it. There is a great deal of effort that is not seen by the stakeholders.
In other words, the blue model above is only showing the tip of the iceberg, and relabeling the phases according to what is (approximately) visible, not what is actually there.
This is an important part of explaining an activity to a stakeholder, and it is a skill that every Enterprise Architect must get good at. You have to explain your activities in the context of what a stakeholder understand and recognizes… not in the context of all your work. It’s not about you. It’s about the stakeholder.
The Rules of Value Streams
There are a few problems with the view above. In order to understand the problems with that view, let’s mention a couple of rules for representing a value stream. We will use these concepts because the ability to describe EA in terms of a value stream is important. Value streams are sticky… they are easy to remember and easy to relate to. If we want to remove the barriers to adoption of EA, we could do far worse than using this technique. That said, there are some rules that we have to keep in mind:
- A value stream does not illustrate dependencies that are not really there. Parallel efforts should be represented as parallel if that would improve understanding of how value is created.
- The value stream is illustrated as a sequence of high level processes in a straight line from left to right. That said, a value stream must start with an event that is relevant to the customer who gets value. It must end with the deliver of that value. Any activity that is not part of that flow (from relevant starting point to value) should be represented “above” or “below” the value stream.
- A value stream should be illustrated in its fully operational state. In other words, it should describe a process that is running, not one that hasn’t been created yet. Events that are relevant only for “start-up” activities can be included, but should not be the primary focus of a value stream.
So let’s apply rule #1. Is it true that the current state of the organization actually feeds the development of strategy? No. In fact, the evaluation of the current state can happen completely in parallel to the development of business strategy.
So the diagram could look like this one.
Here, we can see that there are, in fact, parallel activities for the understanding of the current state of the enterprise, and for the development of business strategy. Where they first intersect is in the development of the future state (the opportunities and solutions phase from the ADM model). You need both an understanding of the current situation and the needs of the future in order to describe where the organization should move towards.
Now, let’s apply rule #2. What is the event that the business considers to be relevant to start the value stream of Enterprise Architecture? The Development of Business Strategy, of course. So the flow should perhaps look more like the diagram below… (note, the arrows and activities are identical to the one above… the only thing different is the order on the page).
Now, let’s apply rule #3… that one is easy. The arrow at the bottom that says “First TIme EA” can simply be dropped. After all, the first time a process is run, it starts from somewhere. It is simply irrelevant to the non-technical stakeholder to point out where that starting position is.
Exception: if you run Enterprise Architecture as a consulting arrangement, you may want to leave that arrow in there. After all, you will need to illustrate where the consulting arrangement will start. That said, I have found that fewer and fewer EA initiatives begin with the hiring of a consulting firm.
When we started with the ADM, we assumed that there was a 700+ page methodology and framework behind the image, describing each step and what is included. However, your stakeholder will not read the TOGAF or any other 700+ page body of information. That would be absurd. You need to add a little detail to the image to describe what is in each of these stages.
It’s also a good idea to “clean up” the diagram a little so that we use less space on the “arrows and boxes” and more engagement on the ideas of what is going on. So the next modification of the process looks like this:
This diagram is a better one for informing the non-technical stakeholders of your Enterprise Architecture program about what it is that you do. We remove a little of the “accuracy” about where an arrow starts and ends, but we add a great deal of context about what is happening along the way.
The “backward” arrow along the bottom clearly indicates that there are activities that flow outside the value stream but which are needed for each repeat of the cycle.
Is this a perfect representation of the EA process? I don’t believe in perfect things… just useful things. But it is better, in my opinion, than showing a non-technical stakeholder the ADM or one of the “box and arrow” models above. It uses the visual language of value streams and business process models, both widely recognized and used in business interactions. It explains itself without going into a lot of detail. And it clearly describes the end to end flow without restricting or dictating where Enterprise Architects start and stop (an important requirement, since maturing EA programs will change their scope as they mature).
I have shown this view to others, and some have wondered about the “backward flowing” process along the bottom. The alternative to showing something as “backward flowing” would be to illustrate it as a cycle (with arrows feeding “in” from the right and “out” from the left). If it is a challenge for you to view the diagram without those arrows, I apologize. I’d love to see other view of this model that illustrate the “cycle” in a way that still meets the “rules of the value stream” as discussed above.
I’d love to get feedback and insight from the community. What do you think? Does the last image above resonate? What would you do differently?
Imagine a future where robots run the hospitals as a way to cut health care costs. A robot ambulance pulls up to the door of the Emergency Room with an unconscious patient. The robot triage nurse connects electrodes to the patient and notices a low heart rate, low blood pressure, and intense pain readings emanating from the abdomen. The diagnosis: blood loss and pain. Prescription: provide blood and pain killers.
Then, in comes a human physician who notices that the patient has a gunshot wound. A surgery team swoops in and removes the bullet and patches the patient up.
OK… time to switch metaphors. Your business is going along, operating normally. A customer comes in the door with a complaint. The product he purchased is broken within a few minutes of getting it.
- Do you respond like a robot and give him a new product and a coupon for 10% his next order?
- Does the physician ever arrive to take a look and decide that the company is manufacturing low quality products? Is anything ever done about the underlying problem?
Enterprise architecture has the same problem in more ways than one.
- If someone complains that the EA team is not providing value, do you respond like a robot and send your architects to jump onto a visible and important project and “be useful?” Do you follow up to diagnose the root cause of the perception? Do you deal with issues in governance, communication, information accuracy, process integration, and expertise?
- If you notice a complex area of the business is never actually getting cleaned up, and that complexity is causing business agility problems, do you create an initiative to simplify the complexity and then stop there, or do you follow up with a project to address the institutional decision making, roles and responsibilities, and design principles that led to complexity in the first place?
A word of advice: when a problem erupts: triage is important, but surgery may be necessary. Don’t solve the underlying problem without dealing with the symptoms. Don’t deal with the symptoms without also addressing the underlying problem.
A few days ago, I blogged about a talk provided by Phil Gilbert at the BPM2010 conference. In that talk, Phil made a compelling case that the smart people who are working on BPM systems and solutions are WORKING ON THE WRONG THINGS. It was a clarion call to action. Phil had to leave the conference and head back to IBM headquarters, but I’ve been able to stay and listen to the results. While I agree with what Phil said, I have not heard any discussions along the lines of “what should we be adding to BPM software in order to address the things that Phil discussed?”
No one is taking the next step to discuss what changes need to be made, to existing software, in order to meet the challenge that Phil described. I’d like to take him up on his challenge and describe a way to create an entire BPM stack that would be useful. First, a summary of the problem.
Phil had been asked to talk about “the future of BPM.” As a former executive of Lombardi software, which was recently acquired by IBM, he has some credibility on the topic. His presentation was very well put together. I summarized his slides to a single image (my apologies to Phil… but this is a blog after all).
If you look at the numbers of people who work in a typical business, you will see that IT folks are a tiny fraction of the total number. The above diagram tries to illustrate an (arbitrary) eight-to-one ratio. This is a good thing. The work of software developers is well leveraged. For a small number of software developers, their work can benefit a large number of business people. (Note: for the sake of this conversation, we are assuming that process modelers actually work for the IT department. The following logic holds true if they do not work for IT, so please bear with me).
This is nice and good, but…
The BPM tools on the market today provide solutions to business people, but are not designed for business people to actually use to solve their problems. A business person has to charter some kind of project, and get one of those rare IT people to come sit with them to model their process and build a custom solution. In other words, IT uses BPM tools. The future of BPM lies in the world where the business uses BPM tools. Why? Because the vast majority of the business value of a BPM solution, according to Phil, comes from the cumulative value of automating a large number of small workflow processes. Phil called them “Excel and e-mail” workflows.
And now, here comes the challenge:
Until we work to bring about BPM democratization, we are doing the wrong things. If we spend considerable time working on the semantics of an OR gate, but we fail to address this concept, we are limiting the reach, and therefore the ability, of BPM to succeed. Challenge: bring about this change.
I asked a few folks about Phil’s challenge. In fact, I asked folks every chance I got. I find the idea fascinating, but I don’t believe we are all that close to it. Here is what I noticed:
First problem… the sales model
Most BPM tool vendors have a sales model that goes like this:
- convince company that they need a BPM tool
- sell them licenses and consulting services
- get the tool installed
- deliver a BPM solution
- show everyone how valuable that was
This behavior creates incentives that drive the spending of the vendor company… incentives that prevent the development of the tool that Phil is calling for. The tool that Phil is calling for can be sold that way, but it shouldn’t. The value of a tool that everyone can use comes when everyone uses it… for a thousand little things. If the BPM solution cannot be installed until there is a big project, then you have a HUGE barrier to getting it installed. Vendors have to focus on that barrier. Unfortunately, that means taking away focus from making those “thousand little workflows” work.
Second problem… one visual language to rule them all
There has been a huge investment over the years in BPMN and in BPEL and, most recently, in the ability to automatically translate BPMN models to BPEL models that, then, produce code. This is an interesting problem, but one that probably does not need to be solved… at least not right now. Unfortunately, it is compelling and technically interesting, so it takes up mindshare of the BPM researchers focusing on creating automated models of business processes. This is a problem because the future depends on creating a large number of small solutions to automate “Excel over e-mail” workflows. Solutions of that size are mostly people oriented, and don’t require complex modeling languages. In fact, for business users, they don’t require ANY modeling languages.
And so we spend tons of time, perfecting a visual language that only the folks in the IT unit can use. We are solving a problem, for sure, but it is akin to restacking the deck chairs on the Titanic. If there is a big problem, and we don’t work on it, what does that say about us?
My suggested solution – business and technical
There is a way out of this conundrum. It involved two key changes. One is to change the business model of the vendor companies themselves, and therefore to change the software that they develop. (That’s right, I’m starting with the business model. Who knew that an EA would do that?) The second change is to the features delivered in the software. Serious investment against new features would need to be made in order to pull it off, but there is no scientific barrier… no technical obstacle. It is a business problem and an investment priority problem, pure and simple.
First off, I’ll put up an illustration.
In this illustration, there are essentially four business scenario (labeled 1, 2, 3, 4). For each scenario, the business user is consuming different amounts of software. The scenarios are in order. The goal is to capture those business people who will adopt BPM in a viral manner, essentially in this order. No big up-front sales process. Users pay for what they need, when they need it. I will discuss the sales process below. The scenarios are:
- Portal only – Most BPM packages include some kind of user interface, most often a web portal, that puts up a list of work items assigned to that particular user. The portal may have other functions as well, like document sharing and simple list management. Let’s change the paradigm. Sell the portal (or give it away). The user, in this scenario, is using the “non-BPM” features of the portal. Note that the BPM capabilities are present, but just not being used. In this case, the customer does not require a license for the BPM engine. (They may require a license for the portal software. I believe in integrated products, so I’d expect that the BPM capabilities would be built in to a portal product, rather than shipped as a completely new technology.)
- Use for common tasks – Most portal packages have the ability to set up a “workspace” or a “room” (welcome to “metaphor stew”) that is particularly useful for generic and common types of tasks. These workspaces are normally focused around some form of collaboration. For example, you may have the ability to set up a simple “article submission and approval” workspace, and it will come preconfigured with a simple workflow that allows authors to submit articles, while editors review and either request updates, or accept for publication. Another editor may assign a particular article to a particular magazine issue. This is good for everything from company or community newsletters to webzines to small-office publishing businesses. The information captured is stored in an non-integrated data store (although web services can be available to allow the data to be drawn out if needed).
- Use for configured tasks – There are a wide variety of basic tasks that most companies need. Things like “update customer information,” “update order information,” “review and update employee information,” etc. The assumption is that this data lives in corporate systems of some kind, and that an adapter must be written to make it available to the web application, but that is all. A developer would write the adapter, but the product would be shipped with about two-dozen basic adapters from which a developer can crack open the code, make a few changes, and run. The BPM product would also ship with 500+ mini-applications, ready to go, requiring only a configured data adapter to be written.
Of course, many companies surround these types of basic tasks with business rules, so the mini-apps must be built in a way that it allows for configuration. In this scenario, the requirements for configuration happen to match the options built in to the mini-application. A developer would make these configuration changes. When a business user wants to use this level of integration, they need to purchase a license for the BPMS. They get the modeling interface as a result.
- Use for custom tasks – when the mini-applications won’t meet your needs, or they need especially complicated information adapters to be built, you have entered this scenario. This is the most complicated scenario, requiring the most sophisticated BPMS software. In this scenario, a developer can start from scratch or from a collection of the “mini-applications” and can build a complete solution from there. The curious thing is that most existing BPMS products already handle this scenario through rich technology (except most products do not provide more than a few sample mini-applications to start from, and mostly they are not written to be configurable so that you only have to change out data adapters).
The beauty of building a BPM package from this viewpoint is that this process of adoption mirrors the way that existing “Excel and e-mail” solutions have come into existence. Most businesses follow this bottom-up path already! It is familiar, if not consciously so, and that makes the sales process much easier.
The (new) sales model
Give the portal package away for free, or build the BPM engine into a successful portal package and get it into businesses by sending out a “new version” of the portal software. Make the upgrade painless, to the point of being trivially easy. The idea is to make all of the pre-packaged common task applications available to business users, as quickly as possible. Also, make sure that they can see the list of mini-applications that they can use if they are willing to spend money and get their IT department to write some adapters. Every common app and every mini-app will have a demo video available on your company web site, with links built into the portal product to allow for discoverable marketing.
When the customer’s IT dept want to build their first few adapters to internal data, let them do it for free. Don’t require a license until the adapter is being used more than 30 times a day. Even then, let it be a nag to the IT and business users for some period of time. The license is simply added to the running system and the nag goes away. Make it easy to click the nag to request the attention of your company’s sales team.
When the customer wants to configure custom business rules or modify the mini-applications, offer really good documentation and then offer consulting services. Many companies will buy the consulting services. Others won’t. Don’t limit the success of your product to those companies that are willing to pay for consulting services.
Mind the Gap
So what do BPMS vendors need to build in order to bring this approach to life? Where should they focus?
- Integrate with a successful portal product. If you don’t have one among your company’s product stack, find a package from another vendor that is successful and offer to embed your BPM engine into it for free distribution. This has to be the most important, and therefore, first thing you do.
- Create twenty-five or more “common task” apps, with prebuilt workflows and local data management. Out of the box solutions. Create a list of a few hundred uses for those common task templates. Modify the process that a portal user goes through so that they will have the right to select one of these solutions.
- Create a stripped down version of your “process state” viewer for the free version of the product. This is used to track those common task workflows.
- Create a taxonomy of data adapters that don’t overlap and from which you can build 500 mini-applications. (This requires a little information architecture.) Build sample adapters on top of common enterprise packages for practice… systems like SAP, Seibel, Dynamics, Oracle, etc. Ship the samples.
- Create 500 mini-applications that meet actual business needs. Poll your customers to find as many different specific situations as you can. Then write a mini-app to match. Get your customers to write a few, and get partners to jump in as well.
- Document the mini-applications and make them available to all customers. Even better, create your very
own iTunes-type of store for your partners to sell their mini-applications on. Make sure that the repository (or store catalog) is automatically called from within the portal product to help your customers find the “newest, latest, and greatest” mini-application to solve their problem.
- Get 20 ‘early adopters’ to put in your ‘upgraded’ portal application with BPM installed. Work with business customers in those locations to get them to set up 50 installations of free common tasks. Write down success stories. Use them to market the heck out of the free side of your application.
Some BPMS vendors are VERY close to this already. They may have some horizontal sample apps but no mini-applications. They may have integrated with a successful portal. These are the vendors that are the closest to success… the closest to meeting Phil’s challenge.
I heard many presentations at the BPM conference. Not every vendor was represented, but of the few that were, they were still offering software to the IT users, not to the business. In order words, no one was focused on actually solving the problem.
This post is an open invitation: go fish.
The field of Business Process Management is not a huge field, but I believe it to be an important one for empowering the transformation of businesses. As an Enterprise Architect, my mission is to accelerate that transformation. Therefore, to be aligned to my own mission, I support the increased use of practices and technologies that remove obstacles to business agility. Business Process Management is one such set of practices and technologies. (There are others, of course).
The BPM2010 conference is a primarily research-based conference steered by luminaries that include Wil van der Aalst, the author of the Workflow Patterns and the YAWL system. Dr. Michael zur Muehlen of Stevens Institute of Technology found me on the blogosphere and asked me to come and present, which I did. I consider myself to be fortunate to be in the presence of people who are as accomplished, intelligent, and visionary as the presenters at this conference. This is the first time that this conference is in the US, and it won’t be back for at least a couple more years. It is a shame that the US is so far behind in helping to develop the science of BPM.
The keynote on the first morning, from Phil Gilbert of IBM (formerly of Lombardi) makes the case that the future of BPM is to embrace the cloud. In addition, he makes the case that we will see the democratization of business process management and the disintermediation of the “experts.”
The notion of democratization is interesting to me. I look forward to that possibility. To be honest, I don’t think we are all that close, but my mind is open. BPM is a highly specific field, requiring considerable training and experience. The development of layers of indirection necessary to truly hide that level of complexity is not yet in evidence. I suspect that the abstractions will be leaky, at least for a long time. Perhaps with the development of more “plug and play” patterns, we can empower average business people to get value out of working with the tools directly. Not sure.
I tried to strike up a conversation on this idea with one of the vendor teams. No luck. I don’t think we are all that close.