In the Middle Ages, the Guild system produced a professional education pathway that began with “apprentices,” who would work and study with an older practitioner, and eventually they would become “journeymen.” If they continued to hone their craft, after a long period of work they could attain the highest level and become known as a “master.” These terms have continued into modern times and if you applied them to Automation, you would find a handful of people that have achieved master status. Peter Warde, “the Rules Architect,” is one of them. Peter has worked as a developer in Enterprise Software for several decades and joined the Decision Management company ILOG in 2006, where he worked on some large, high-profile accounts. After IBM acquired ILOG in 2009, Peter did the same thing for IBM customers. He became an independent contractor in 2011, offering his services as a leading expert in Decision Management. He’s also a prolific blogger on Best Practices in Decision Management and his posts (link to recent blog) have been very popular on the Business Automation Community. Recently, I had a conversation with Peter, from his office in London (he has another office in Paris) and we got deep into the concepts of Decision Management.
DJ: As a Decision Management expert, do you have a particular industry angle? Or would you say your practice is cross industry?
PW: I’m not specialized by industry. I’ve worked on many projects for insurance, government, banking, financial services, travel and transportation, and logistics. I have a lot of experience in logistics.
DJ: How does Decision Management get operationalized in Logistics?
PW: Decision Management starts with rules and regulations. When you move goods across the world, you can move goods across trade areas, across countries, and within countries. Each has a different set of rules. There are rules through the logistics lifecycle – from receipt to import/export, then loading, then shipping. There will be rules specific to various countries. If a shipment comes through Cuba or Iran, you have those kinds of rules. There are rules about equipment, like cranes and what size containers you can use. And then there's rules about commodities, what you can ship and what you can’t. And if you’re shipping into Europe, for example, you can come into certain ports, but not others. It's a really fascinating. For any Decision Management process, you must research to learn about the business, and with logistics, it means understanding tens of thousands of rules.
DJ: When a company engages you, do you have a particular place you start? Or is it always different with every client?
PW: It's always different. It's always best to work on a green field site, because then you can get it set up right.
DJ: But I imagine you see legacy systems too that need sorting out? Have you been a Decisions Doctor?
PW: If I’m called into a project that’s been going for a while, it's usually because something's gone wrong. Then it gets complex. There may be political forces at work, sometimes contractors have promised shortcuts that didn’t really work. Getting a project back on track is a particular kind of specialty, requiring very specific skills. If you want to build something that's maintainable, stable, and it's going to last for years, then you’re better off starting from the beginning.
DJ: Operational Decision Manager (ODM) is IBM’s flagship Decision Management software product. You’ve built a career on your ability to create applications with it. Why ODM?
PW: ODM is a full-scale business rules management system. It allows you to work more to the enterprise level. I also have IBM BPM skills. Workflow and decision management is a powerful combination. ODM enables you to build a repository of rules and then externalize decisions for business processes to create smarter business processes. With ODM, you can build business vocabulary – everyday language – into business rules and then assemble business rules into decisions. By extracting the rules from a repository into the decisions you’re building, that allows for decisions to be consistent across the enterprise. And when a regulation or business policy changes, you simply change it in the repository, not on every little decision you’ve automated.
DJ: Why is using business vocabulary important?
PW: Because business vocabulary is business knowledge. And the only way to be successful with Automation is to focus on the business. You have to show business value. It's always about money, whether it's regulation and avoidance of fines or an increase in profit margins - that is what it's about. It's not about technology. You need to show the organization that you can make money with Automation. You're not just offering the latest groovy technology. Technical people can spend too much time talking about technical things.
DJ: You’re a technical person, aren’t you?
PW: Yes, but if I sit down with the business owner of a process and talk technical, how do we collaborate? When we design decision automation, we need to have a business conversation, not a technical conversation. For example, I can ask a car insurance analyst, “Is it true that a person who’s 18-21 should pay a premium on their car insurance?” And the analyst can answer, “It’s only true if they drive a sports car.” That’s a conversation that you can build a business strategy on. You can validate stuff with them when you use business vocabulary. I can’t show them my code and expect them to understand. Business rules always start with the business.
If you liked this conversation with Peter Warde, send him a note through the Community and start a conversation.