Well if you hadn't heard the news, M$ is now all about the model which is great. However it's horses for courses one persons model isn't necessarily another's e.g. business analysts versus tekkie models have different goals. Translating from higher level to lower (closer to the metal) models is complex.
There were a couple of demos that showed the generation of BizTalk orchestrations from a business process model designed by an business analyst (the companies behind the tools shall remain nameless). For the uninitiated the demos look great; anyone who has been baptized in the fires of BizTalk can immediately see the danger.
A business guy describes his process but doesn't realize the operational implications of his description or decisions e.g. 'I have a business process that receives a PO and sends a request to an ERP system, then in 90 days if we don't get paid we chase the money'. Picture the model he/she could draw; you got it delay for 90 days. Do we really want an orchestration that hangs around for 90 days?
What happens if we want to upgrade this orchestration?
What happens if 90 days becomes 110 days?
What happens if someone unenlists the orchestration?
We would want to break the process into smaller shorter-running manageable steps not just one big orchestration. IMHO these tools are dangerous in the wrong hands, they should come with a 'use with care' sticker on the front.
On the flip side Jon Flanders just released a workflow to BizTalk xlang wizard. Now this is different; typically a WF workflow has been designed with a lot of the same considerations in mind that one would have when designing a BizTalk orchestration. Therefore you are converting like with like.
The dissonance between the models that business analysts and tekkies produce is difficult to reconcile. Role on Oslo ;0)
1 comment:
You're quite right. It could be a dangerous tool in the wrong hands. IMO, this was always the problem with the ODBA. Business Analysts do not have enough tech knowledge to design orchestrations and we shouldnt be trying to flatter them into thinking they do. However, some biztalk designers use the ODBA for the design planning meetings which makes more sense than having a BA use the tool. Thats why Oslo tools could be a double edged sword. Being able to generate orchestrations from models that we can quickly draw when working through designs with colleagues can be useful to get the solution structure in place. Turning that into production code is entirely a different matter.
cheers
benjy
Post a Comment