On Windows Workflow and Biztalk
From each of these technologies I have a book laying around on my bookshelf somewhere. For WF, I have bought Essential Windows Workflow Foundation about 1 year ago. Since then, I’ve read the introduction about 15 times. After reading the intro, I always put it back on the bookshelf again. Every time I did this, I asked myself the question whether I needed something this complex for solving such a simple problem. I mean, how hard is it to write a state machine in code that you need a designer to do it?
Some time ago, I was in a meeting discussing yet-another-self-developed-GUI-framework. During this meeting, the use of Windows Workflow was demonstrated for handling page flows. When showing this in Visual Studio, it literally blew up taking Visual Studio down with it. Then I realized for the final time, that a Windows Workflow or Biztalk solution is too complex for solving the simple problems it was designed to solve and just too simple for solving complex problems.
What is wrong with mouse-driven development you may ask? Besides the fact that it is not productive (ask JP about this), there is one major problem with using a graphical designer: it only serves the needs that its builders have incorporated. The moment you are in a situation that falls outside the main scenario’s, you are out of luck. Add to this fact that graphical designers are typically very narrow in scope.
Now, I can prove this. At my current employer, I already rewrote two unmaintainable Biztalk applications that were written by drive-by architects. These Biztalk applications were very unstable. Developers and infrastructure people were literally terrified just looking at them. How on earth did I manage to refactor a complex Biztalk application with a flow that doesn’t fit on 5 pages and that sends and receives messages from another component using remoting? Well, first I needed two weeks in order to figure out what the hell it was doing (so far for the documentation argument in favor of WF). Then, I wrote a console application in about 3 days with 200 lines of code. This console application had one single minor bug on the first week after it went into production (I did something wrong with a Mutex: just my stupid fault). No more problems and issues were reported until this very day. Simplicity prevailed and it felt sooooo good!
After reading Workflow software: I’m calling the bluff on Leon Bambrick’s blog (a fantastic post I must say), I’m definitely pulling the YAGNI card on WF and Biztalk. I’ll also be moving the WF and Biztalk books from my bookshelf to a box on my attic, hoping that I’ll never need them throughout my further career. Whenever I see or feel the need for using WF or Biztalk, I’ll immediately start looking for a much simpler solution.
Agree that WF & Biztalk are complex, and certainly can be an overkill for some situations.
However, there is a breaking point. BT is the lifes blood of our organization. We are currently managing 5500 different connection point combinations to hundreds of customers over every protocol imaginable, and wouldnt you know almost each one of those customer documents are different in some way and require a unique mappings to supported internal cannonical document types. In comparison to many BT implementations, we are the little guy 🙂
To me, theres just no way you could do something like this without BT. (or another more expensive overly complex solution)
Hi Jarod,
Of course I don’t know the particular requirements, but when It comes to maintainability and solubility, my experiences with Biztalk are not that great. The Biztalk applications we still have in production right now are just as easy developed with less code. I always strive for the simplest solution possible. Hence, if I can rewrite one more Biztalk application using a much simpler solution, I get the title ‘Biztalk killer’ 😉
However, I’m really glad that it works out for your company. It could be worse.
Jan,
I discovered WF at New England’s Code Camp (4/1/07). Initially, I was very impressed. I *thought* that I could fit this seemingly round peg into a lot of round holes.
Unfortunately, when I began to consider ways to employ WF, I too discovered that the technology was a bit more obtuse than I had originally considered.
Your post struck a chord with me. Barring any convincing evidence to the contrary, I’m also left to invoke YAGNI on WF.
Thanks for putting things into perspective.
I agree that WF and BizTalk are not the right tools for many of the typical solutions we developers have to solve on a daily basis. As you already stated the learning curve and added complexity is just not warranted for many projects. It is like using a sludge hammer to pound in a tack to hang a picture on the wall. Using the right tool for the right job at the right time, with the correct implementation.
However, I have to strongly disagree that these tools do not have their place in the universe. I do not consider myself a BizTalk guru, but I have taken all the certifications exams, taken the New Horizon training, done a few POC projects for one of the companies I worked for and been to Redmond a couple of time for their EAI (enterprise application integration) conferences where I was able to speak with in great detail representatives from some of the United States and European mega corps who use BizTalk. These individuals were all invited to these conferences to show off their implantations of BT. They all came with data showing how their organization greatly benefited from implementing and EAI tool like BT.
http://en.wikipedia.org/wiki/Enterprise_application_integration
BT when used for what it is intended for (in my opinion) i.e. an organizations central service bus can save an organization substantial revenue. BT is not just about the graphical orchestration designer, in fact you do not event have to use the orchestration designer. BT is a true and very good EAI tool Connecting dispirited systems through adapters i.e. allowing you to make point to point connections between just about any system on the planet. If you are using BT as your service bus glue, your organization can take advantage of its built in message transformers, BAM (business activity monitoring) and BAS (business activity services) through a simple to use SharePoint Portal. Then when you add in its data warehouse ties to Analysis Services , wow you have one powerful platform that can give you tremendous insight into the way data flows through your organization.
It would take a fleet of engineers to develop and manage a custom solution to do what BT or other EAI tools like it can for a large organization. In all the successful implementations I have seen of BT they all have a designated team of people who managed the BT infrastructure. Just on what I have seen if a company is going to use BT then they need to have a team of BT specialist to manage and implement it. It is to complex of a tool to just through a couple of developers at it and expect them to be successful. Again, goes back to my statement about correct implementation.
I do not consider WF in the same sphere as BT. In fact the only thing they have in common is the visual orchestration designer. One use I see for WF is a tool where you need high cohesion with your business units in the development of your code flow. I once worked in a very large manufacturing setting that had insanely complex business logic rules and code flow in the code base. By placing this code flow in a visual designer our manufacturing engineers who were the business experts could easily help us manage the system with great accuracy. All tools have their place, it’s up to use to determine the if and when all these tools in our tools box should be used.