How to combine Workflow and Business Rules – in 5 easy steps

June 15, 2008 6 Comments

Tom has a good post on the jBPM (JBoss workflow) community day held at the Guinness brewery in Dublin. Warning – slides may contain pictures of people drinking beer.

Drools jPBM Business rules presentation

How to combine (jBPM) Workflow and (Drools) Business Rules – here’s the summary. Slideset is available on this blogpost.

  • Workflow (e.g. JBoss jBPM) is great – it allows you to take spaghetti code and draw it as a workflow diagram (flowchart) so that it can be reviewed by the business (the nice people who pay our wages). You then attach standard (Java) actions to these steps.
  • Only problem is when you come to a decision node (the one circled in red below): How do you decide to go left or right (in the workflow)? Normally this is coded in Java – good for us, but hidden from those nice business people (which means that this is more room for errors-in-translation).
  • Business Rules allow you to keep those decision making rules in Plain English: When something is true , then do this. That’s it. The rule engine does most of the hard work.
  • Integrating Workflow and Rules is easy. Use JBoss Seam (link) or do it by hand (link). And it works on non-JBoss web / app servers such as Websphere, Oracle Application Server, Tomcat and Weblogic.
  • Repeat x6 : Use workflow and rules. Use workflow and rules …

Simple Workflow

In a maybe related development, Tom Baeyens is now using strangely Rules-y like examples over on his workflow blog ….

Filed under BPEL, BPM, drools, Dublin, enterprise, enterprise java, enterprise web 2.0, Events, java enterprise, Java Enterprise Edition, Knowledge Management, People, presentation, Process, Rule Engine, Workflow

Business Process Management is Service Orientated Architectures Killer Application

August 21, 2006 Leave a comment

Ismael Ghalimi has put it in a nutshell:

BPM is Soaps Killer Application

  • BPM or Business Process Management , is the art / science of capturing what your staff actually do in an IT system (and hopefully help them do their job better in the process).
  • SOA or Service Orientated Architecture is designing your system as a set of endpoints (e.g. Login, get bank balance, transfer money, logout). Most systems already have this functionality, although maybe not clearly laid out.

Ismael goes into more detail , but the idea is that BPM (think Visio Diagram) allows you to draw your workflow. Each step on the workflow is carried out put an action / endpoint provided by some system (using the SOA type design).

Filed under Architect, BPM, Business, EnterpriseWeb2.0, Knowledge Management, Process, RedPiranha, rp, SOA

Fixed Price? Don’t get Stung

June 30, 2006 Leave a comment

Chances are , you get get paid on a ‘Time and Materials’ basis – either as an employee or a consultant. Chances are, you’ve also thought that some extra work , perhaps at a fixed price, would be a nice sideline. Before you dive in, remember the following 5 key points.

  1. Write a Project Outline. Say exactly what will (and just as importantly) won’t be carried out as part of the project. This can take a lot of time to put together, but is essential to avoid trouble later. Even better get the client to pay you to write this, as it’s vital for them as well.
  2. Client dependencies. Do you depend on the client to get things done? If so, specify exactly what the must provide and when. Can’t specify exactly when you need (and there are many projects where this is the case)? Then do the work on a time and Materials basis only.
  3. Be visible to end client. The temptation is to go into a dark corner and start coding. The trouble is that you emerge blinking into the daylight at the end to find (i) The client frantic with worry about how the project is going and (ii) that events have happened that you sh. ould have known about. Price in regular time on the client site to keep in touch.
  4. Contingency. A wise man once said (In this case the instructor at the PMBOK course in Chicago): ‘If you can’t carry out the project with 15% time left over , don’t start it. For fixed price projects, make this something like 30% as the client will ask you to do little ‘extras’ and you can’t ask for extra money for every single one.
  5. Almost as important as knowning when to start (see point 1) is knowing when to finish. Document everything and do a final ‘handover’ day (a good idea is to hand over a CD whith all project deliverables on it). If you don’t do this, the project will never end, and you will never get paid.

Notice that all these items are about process , and not technology. Put simply; you can mess up your project just as easily using Java , PHP or .Net . Mess up as an employee or consultant, you get shouted at by the boss. Mess up on a fixed price and you’re into serious pain as you burn through (unpaid) extra time.

Filed under Business, Consultant, Consulting, Development, Entrepreneur, Process, Project

What comes after Java and .Net? Agents.

June 9, 2006 2 Comments

Most systems until now have been centralised : A bit like the old Soviet Union, everything is centrally planned. The trouble is real-life isn’t like that – it’s a market economy with no central control. There’s a story about a Russian Diplomat posted to New York in the 60’s. On a visit to a bakery he asked – who decides how many loaves are baked in the city? The answer is no-one – each baker individually decides how many to bake based on how many he sold the day before. Somehow (almost) everybody gets fed.Current OO systems are like the Russian’s view: everything is centrally controlled. Agents are more like New-York (or Dublin) city today – a place full of people (agents) acting in their own self interest. Somehow everything works ok. Economists have a theory that backs this up ; in general a set of people acting in their own self interest gives the best solution at a global level. Or, if you prefer it’s a bit like Ants. Individual Ants are stupid, but together they are clever enough to mark a trail to food and carry it back to the Anthill. It’s called Emergent Behaviour – simple programs combining to give the answers to complex problems.

How does Web 2.0 give a push to Agents? Before, Systems were standalone , and everything planned in advance. With Web 2.0 everything is connected and too complex to manage by one person. We need to look at what works successfully in real life. Just as Market economies overcame the ‘Command and control’ of communism, so Agents will overcome the Command and control of Objects. It may not be perfect, but it will be (slightly) better.

Will agents replace Java and .Net ? A sign that ‘the future is already here’ is that when you read the list ‘what makes an agent’ , you may go ‘but we’re doing that now’. Java and .Net have been around for so long now that it’s easy to forget the Object Orientated Programming (OOP) was once a radical new departure. It’s also easy to forget that languages such as C++, Visual Basic 6 and Powerbuilder were once ‘king of the hill’ and commanded respect from your colleagues when you mentioned your latest project was using them.

So what are agents? Compared to Objects :

  • Agents act in their own self interest , they may decline a request if they think it makes them better off.Objects always respond to a request.
  • Agents have their own thread of control , 1 for each agent. Objects may have their own thread, but most objects don’t. – Agents are pro-active, and seek to improve their lot , according to pre-defined goals.
  • Agents are ‘Coarse Grained’ that is, a system will probably have a few agents will a lot of normal , dependent , objects. It’s similar to the way Enterprise Java Beans are used : not everything is an EJB , and there a still lots of Plain Old java Objects.
  • Objects are designed from the start to work together. Agents can be written by different people , perhaps with widely different goals in mind.

Just like C++ was a procedural language with object orientated ‘bits’ attached, Agents are currently implmented in languages like Java , with agent-y bits attached. Probably the most useful set of bits is Cougaar. Cougaar is an open source project with a live community at Cougaarforge and an Eclipse based IDE. Cougaar gives you the basic infrastructure for creating and managing agents.

Of course , there’s nothing to stop you building your own agents. According to the above definition, most systems that have workflow tieing together entities making decisions according to their own business rules are not far off being agents. Especially when they have a scheduler (i.e. their own ‘thread of control’).

What do you think? Leave a comment below.

Filed under Architect, JBoss, Knowledge Management, Process, Rule Engine, Web, Web 2.0, Web2Ireland, Workflow

Architecture? One size fits all

May 6, 2006 1 Comment

No matter what your system does , be it insurance , banking , online travel booking or telecoms, the chances are it does the following things:

  • Gets information from users over the web
  • Does some business processing on that information
  • Saves the information in a database.

At a conservative estimate , about 99% of Enterprise systems would fall into this category.

If so, why do you need an architect , when you can use our ‘one size fits all’ architecture diagram (below)?! Most non-trivial systems, regardless of the language they are written in (be it Java, .Net , or your language of choice) follow the pattern seen in this diagram.

3 Tier Enterprise Diagram

There are 3 Pieces to the Solution:

  • Web Browser (for the user / client).
  • Web and Application Server – carry out business logic.
  • Database Back End – to store data and ensure data integrity.

Within the Application Server (the middle bit above, which as Java Architects is the bit we are interested in), there are a further 3 tiers

  • A Presentation tier (or layer), which is mainly about talking to the user (it gets and sends requests to the web browser).
  • A Service layer , which is mainly about talking to back end such as databases, legacy systems (such as mainframes) and XML-Web services that we may use.
  • A Business layer, the ‘meat’ of the sandwich, where the ‘Value add’ is in terms of business processing and validation.

For each of these layers , your priority in building them are slightly different.

  • The Presentation layer is the bit the user sees. You want it to be fast and give a good impression to the client. Underneath, use a standard framework (link: pick your framework here) and then customize the look and feel.
  • The Service layer you want to work fast and well (e.g. no data faults), but then then forget about. Unless things go wrong, no user is going to complement you on the quality of database persistence! Use standard libraries for the entire layer.
  • Unless your company is a clone or franchise, the business layer in the system is going to be completely different. Aside from the user-interface , concentrate most of your project effort here as this is the core of what system does. We’ve written quite a bit about how to increase the value-add of the business layer (link to O’Reilly Technical Articles)

By the way , we’re only half-joking about the ‘why do you need an architect’ bit. We can be contacted here.

Filed under Articles, Business, Consultant, Consulting, Finance, Government, Health, Knowledge Management, Process, Rule Engine, Technology, Workflow

It's been very quiet over here (aka what has Paul been up to) – Enterprise Web 2.0

April 20, 2006 1 Comment

It’s all been very quiet over here , too quiet. And not just because of the hosting issues (the people at Netbunch, you know that I’m talking about you)

It’s been very quiet , because I’ve been very busy. On top of all this , we’re coming to the end of the year for the (part time) Masters at UCD in Dublin, so we’ve also got exams coming up. Thankfully it’s the last year, the downside being I have a dissertation to write.

Being a blogger , I’m not happy putting together a weighty tome that will sit gathering dust on a shelf. Instead , I want something that will solve some business problems , and that I can use as interesting content. So after much thought , the proposed title of my dissertation will be …… cue drum roll ….. ta-da!

Enterprise Web 2.0

Now, if you’ve talked to me , you know I spend a lot of my working day as an Enterprise Java Consultant , working for various banks. The idea is to take some of the Web 2.0 ideas (and you don’t need me to repeat them) and apply them to the sort of problems large companies have. Or , if you want the catchy subtitle , ” it’s all about sucking the knowledge out of people’s brains and putting it onto (ugly) websites”.

So an obvious topic to cover is the use of Ajax , which while big on the web at the moment , is going to be huge once companies realise what it can bring to their internal applications. The rest of the topics cover knowledge management (what is web 2.0 if it’s not about sharing knowledge), but also some tools and techniques that will all Enterprise Java (with all it’s robustness and scalability) compete with the nimbleness and tricks of Ruby.

Business Problem 1: How to present this information to people in a easy to deploy, but powerful way.
Solution: Update to Sun Java article – this one on how to do Web 2.0 / Ajax ‘right’ in Enterprise Java (i.e. not worrying about legacy code)

Business Problem 2: Where you have documentation, but don’t know how to find it.
Solution: Write up of the Red-Piranha Adaptive Search engine that ‘learns’ what the team wants , and finds more of it.

Business Problem 3: Where you have information in Excel sheets, but can’t do much with it.
Solution: Update to previous O’Reilly Articles on JBoss Rules – this one on JBoss’ ability to ‘run’ Excel Spreadsheets.

Business Problem 4: Where you have information that people ‘know’ , but that a machine finds it hard to ‘learn’
Solution: Simple Neural Networks using Joone, applied to a ‘real life’ business problem.

Business Problem 5: Where several people have to work together on a set of information , following a strict set of steps.
Solution: JBoss workflow, with a simple online example

Filed under Ajax, Architect, Articles, Business, Dublin, Ireland, JBoss, Knowledge Management, Lucene, Process, Rule Engine, Training, Web, Web 2.0

More information on How to talk to your boss about agile projects…

March 7, 2006 2 Comments

Will update this with feedback from the ‘How to talk to your boss about agile’ event, but in the meantime, here is all the slides and links to articles used in the Agile presentation.

Filed under Agile, Development, Dublin, Events, JUnit, Networks, NoUnit, presentation, Process, Project

How to talk to your Boss about Agile

March 5, 2006 5 Comments

We’re giving a talk about ‘how to talk to your boss about agile‘ for the Irish .Net Developers Association next Tuesday in Buswells hotel Dublin.

More details (including the slides themselves, as a preview of what you are missing) are available here in powerpoint, openoffice, pdf and flash formats. The slides explain how 4 pictures of bridges can explain the difference between Ad-Hoc , Predictive, Agile and XP projects. No , really , you do want to check this out.

Links to a lot of the sites / articles / tools used in the presentation are here on Del.icio.us. More posts on this blog about using agile techniques on projects are here.

The Bridges are:

  • Old Drogheda Bridge from the 1200′s – Quick and Dirty or Ad-Hoc project. Got the job done , and fast . Was patched a load of times, but eventually fell down under the weight of the traffic.
  • New Drogheda Motorway Bridge – Predictive Projects. Very easy to specify what you want (I want a bridge going from A-B to carry a motorway) and very easy to know when you are finished.
  • Drogheda Railway Brigde – Agile. Once the longest Iron Girder bridge in the world.Built in the 1850′s and the spec has kept on changing since. This included a complete rebuild in 1925 without losing a single days traffic. How’s that for unit testing?
  • Bungee Jumping off bridge in Queenstown – Extreme Programming (XP). Great fun if you’re doing it (and can be pretty effective), but scary for anybody watching.

As a sample of some of the pictures (which include lego people showing everything that can go wrong on a team), check out the image below.

source the brick testament.com.
Image from
TheBrickTestament.

Filed under Agile, Architect, Business, Ireland, Location, Microsoft, Networks, NoUnit, presentation, Process, Project, Testing

JBoss Workflow JBpm and JBoss Rules (Drools)

February 21, 2006 4 Comments

Notes from this Post on the Serverside

 I recently wrote an O’Reilly article on one of the related JBoss projects the Drools / JBoss rules engine.

Just to get the difference between jBPM and Drools / JBoss Rules straight in my head:

- Workflow tends to be ‘wide’ where Rule Engines tend to be  ‘deep’.

- Workflow is wide as the flow is spread over different people / actors and over time.

- Rule Engines are ‘deep’ as they apply simple rules to solve complex problems, but in general the rules are applied ‘all at once’.

Some of the confusion (in my head at least) comes from the fact:

- It is possible to implement workflow using a rules engine, much as it is possible to write your own workflow using Java. Of course , you don’t get the graphical designer that JBpm has.

- Both JBoss Rules (Drools) and JBoss Workflow (jBPM) see to
‘externalize’ part of the solution outside of Java. By stepping outside
of Java to use an XML / Graphical based approach, it makes the solution
easier to configure and understand.

Filed under JBoss, Process, Rule Engine, Technology, Uncategorized, Workflow, Xml

How to avoid losing 150m Euro

February 3, 2006 1 Comment

It now seems obvious that the Healthcare Payroll system was destined to fail. If you were working on the project, I’m sure it felt very differently at the time. How can your projects avoid a similar fate? While IT may sometimes seem disconnected from reality, the following guidelines show that ‘Real World’ lessons still apply.

  1. Know what you want and stick to it. If you’re building a house and change the plans several times the builder is going to fleece you, no matter how low the initial quote was. The same goes for IT Projects – if you change your mind after the price is agreed, you’re going to pay more.
  2. If you don’t know what you’re doing , find a friend who does. I know very little about houses, so when I was buying my own I got a friendly surveyor to check it out. With IT projects, this ‘friend’ should be genuinely on your side, and have something to lose (e.g. financial or reputation) if things go wrong.
  3. Little and often is better. Like exercise, smaller projects that deliver results little but early are best. If the results are good, try a second (and third) round to add more functionality based on the feedback from users.
  4. It’s been all done before. Tailored suits cost a lot more than ready-made ones – and most people are happy with a ‘Good enough’ instead of ‘Perfect fit’. There are literally thousands of ‘off-the-peg’ computer systems out there ready for final alteration to what you need.
  5. If you don’t understand the answer, ask more questions. Thankfully the days we sat and nodded at the Doctor’s Latin words are long gone. IT Consultants may sometimes speak a different language, but if they can’t explain what they’re talking about in English that you understand, the chances are they’re trying to hide something.
  6. Don’t build on sand. Like houses , projects need good foundations. For IT Projects , the good foundations are sound knowledge of the Business Processes being coded into the system. Changing processes and changing IT systems at the same time is like building on sand.
  7. Sometimes the tortoise wins the race. Unless your entire business model is built around being the very first to market, then being a tortoise and letting others race ahead has very big advantages. Not only can you learn from other people’s mistakes, but the chances are you’ll get it at a much reduced cost – For example websites now cost a fraction of what they did during the dot.com boom.
  8. Use a safety net. When building houses, often the first thing to go up is scaffolding, for safety reasons. The equivalent safety net in IT is called ‘Unit Tests’. Not only do they help you get there faster, but they let you know if you’ve broken something you’ve already built.
  9. Be a good poker player. Good poker players never give away valuable cards. For IT projects, owning all cards mean just that – make sure that you have full rights to the solution so that you can still move tables and use a different supplier. Even if you never make the move, knowing that you can is an effective bargaining chip.

And finally …

When you are in a hole, stop digging. The decision to call a halt to the projects was no doubt a difficult one, and is to be applauded. Too often, the temptation is to keep on going and hope things will turn out right. Recognising problems at an early stage means there is more chance of being able to fix them.

Filed under Agile, Architect, Articles, Business, CRM, Dublin, ERP, Finance, Government, Health, Ireland, Open Source, Process, Project

← Older posts

Follow

Get every new post delivered to your Inbox.