Q: You head up the UK SOA/BPM User Group (and I’m looking forward to my invitation to speak there). What are the topics that generate the most interest, and what future topics do you think are most relevant to your audience?
A: Firstly, yes we would love you to speak, and ill drop you an email so we can discuss this 🙂
The user group actually formed about 18 months ago when two groups of people got together. There was the original BizTalk User Group and some people who were looking at a potential user group based around SOA. The people involved were really looking at this from a Microsoft angle so we ended up with the UK SOA/BPM User Group (aka SBUG). The idea behind the user group is that we would look at things from an architecture and developer perspective and be interested in the technologies which make up the Microsoft BPM suite (including ISV partners) and the concepts and ideas which go with solutions based on SOA and BPM principles.
We wanted to have a number of themes going on and to follow some of the new technologies coming out which organizations would be looking at. Some of the most common technology topics we have had previously have included BizTalk, Dublin, Geneva and cloud. We have also tried to have some ISV sessions too. My idea around the ISV sessions is that most people tend to see ISV’s present high level topics at big industry events where you see pretty slides and quite simple demonstrations but with the user group we want to give people the change to get a deeper understanding of ISV offerings so they know how various products are positioned and what they offer. Some examples we have coming up on this front are in January where Global 360 will be doing a case study around Nationwide Building Society in the UK and AgilePoint will be doing a web cast about SAP. Hopefully members get a change to see what these products do, and to network and ask tough questions without it being a sales based arena.
Last year one of our most popular sessions was when Darren Jefford joined us to do a follow up to a session he presented at the SOA/BPM Road show about on-premise integration to the cloud. I’m hoping that Darren might be able to join us again this year to do another follow up to a session he did recently about a BizTalk implementation with really high performance characteristics. Hopefully the dates will workout well for this.
We have about 4 in person meetings per year at the moment, and a number of online web casts. I think we have got things about right in terms of technology sessions, and I expect that in the following year we will combine potentially BizTalk 2009 R2, and AppFabric real world scenarios, more cloud/Azure, and I’d really like to involve some SharePoint stuff too. I think one of the weaker areas is around the concepts and ideas of SOA or BPM. I’d love to get some people involved who would like to speak about these things but at present I haven’t really made the right contacts to find appropriate speakers. Hopefully this year we will make some inroads on this. (Any offers please contact me).
A couple of interesting topics in relation to the user group are probably SQL Server, Oslo and Windows Workflow. To start with Windows Workflow is one of those core technologies which you would expect the technology side of our user group to be pretty interested in, but in reality there has never been that much appetite for sessions based around WF and there hasn’t really been that many interesting sessions around it. You often see things like here is how to do a work flow that does a specific thing, but I haven’t really seen many cool business solutions or implementations which have used WF directly. I think the stuff we have covered previously has really been around products which leverage workflow. I think this will continue but I expect as AppFabric and a solid hosting solution for WF becomes available there may be future scenarios where we might do case studies of real business problems solved effectively using WF and Dublin.
Oslo is an interesting one for our user group. Initially there was strong interest in this topic and Robert Hogg from Black Marble did an excellent session right at the start of our user group about what Oslo was and how he could see it progressing. Admittedly I haven’t been following Oslo that much recently but I think it is something I will need to get feedback from our members to see how we would like to continue following its development. Initially it was pitched as something which would definitely be of interest to the kind of people who would be interested in SBUG but since it has been swallowed up by the “SQL Server takes over the world” initiative, we probably need to just see how this develops, certainly the core ideas of Oslo still seem to be there. SQL Server also has a few other features now such as StreamInsight which are probably also of interest to SBUG members.
I think one of the challenges for SBUG in the next year is about the scope of the user group. The number of technologies which are likely to be of interest to our members has grown and we would like to get some non technology sessions involved also, so the challenge is how we manage this to ensure that there is a strong enough common interest to keep involved, yet the scope should be wide enough to offer variety and new ideas.
If you would like to know more about SBUG please check out our new website on: http://uksoabpm.org.
Q: You’ve written a lot on your blog about testing and management of BizTalk solutions. In your experience, what are the biggest mistakes people make when testing system integration solutions and how do those mistakes impact the solution later on?
A: When it comes to BizTalk (or most technology) solutions there are often many ways to solve a problem and produce a solution that will do a job for your customer to one degree or another. A bad solution can often still kind of work. However when it comes to development and testing processes it doesn’t matter how good your code/solution is if the process you use is poor, you will often fail or make your customer very angry and spend a lot of their money. I’ve also felt that there has been plenty of room for blogging content to help people with this. Some of my thoughts on common mistakes are:
Not Automating Testing
This can be the first step to making your life so much less stressful. On the current project I’m involved with we have a large number of separate BizTalk applications each with quite different requirements. The fact that all of these are quite extensively tested with BizUnit means that we have quite low maintenance costs associated with these solutions. Anytime we need to make changes we always have a high level of confidence that things will work well.
I think on this project during its life cycle the defects associated with our team have usually been <5% related to coding errors. The majority are actually because external UAT or System test teams have written tests incorrectly, problems with other systems which get highlighted by BizTalk or a poor requirement.
Good automated testing means you can be really proactive when it comes to dealing with change and people will have confidence in the quality of things you produce.
Not Stubbing Out Dependencies
I see this quite often when you have multiple teams working on a large development project. Often the work produced by these teams will require services from other applications or a service bus. So many times I’ve seen the scenario where the developer on Team A downs tools because their code wont work because the developer on Team B is making changes to the code which runs on his machine. In the short term this can cause delays to a project, and in the longer term a maintenance nightmare. When you work on a BizTalk project you often have this challenge and usually stubbing out these dependencies becomes second nature. Sometimes its the teams who don’t have to deal with integration regularly who aren’t used to this mindset.
This can be easily mitigated if you get into the contract first mind set and its easy to create a stub of most systems that use a standards based interface such as web services. I’d recommend checking out Mockingbird as one tool which can help you here. Actually to plug SBUG again we did a session about Mockingbird a few months ago which is available for download: http://uksoabpm.org/OnlineMiniMeetings.aspx
Not considering data flow across systems
One common bad practice I see when someone has automated testing is that they really just check the process flow but don’t really consider the content of messages as they flow across systems. I once saw a scenario where a process passed messages through BizTalk and into an internal LOB system. The development team had implemented some tests which did pretty good job at testing the process, but the end to end system testing was performed by an external testing team. This team basically loaded approximately 50k messages per day for months through the system into the LOB application and made a large assumption that because there were no errors recorded by the LOB application everything was fine.
It turned out that a number of the data fields were handled incorrectly by the LOB application and this just wasn’t spotted.
The lessons here were mainly that sometimes testing is performed by specialist testing teams and you should try develop a relationship between your development and test teams so you know what everyone is doing. Secondly executing millions of messages is no where near as effective as understanding the real data scenarios and testing those.
Poor/No/Late Performance Testing
This is one of the biggest risks of any project and we all know its bad. Its not uncommon for factors beyond our control to limit our ability to do adequate performance testing. In BizTalk world we often have the challenge that test environments do not really look like a production environment due to the different scaling options taken.
If you find yourself in this situation probably the best thing you can do is to firstly ensure the risk is logged and that people are aware of the risk. If your project has accepted the risk and doesn’t plan to do anything about it, the next thing is to agree as a team how you will handle this. Agree a process of how you will ensure to maximize the resources you do have to adequately performance test your solution. Maybe this is to run some automated tests using BizUnit and LoadGen on a daily basis, maybe its to ensure you are doing some profiling etc. If you agree your process and stick to it then you have mitigated the risk as much as possible.
A couple of additional side thoughts here are that a good investment in the monitoring side of your solution can really help. If you can see that part of your solution isn’t performing too well in a small test environment don’t just disregard this because the environment is not production like, analyze the characteristics of the performance and understand if you can make optimizations. The final thought here is that when looking at end to end performance you also need to consider the systems you will integrate with. In most scenarios latency or throughput limitations of an application you integrate with will become a problem before any additional overhead added by BizTalk.
Q: When architecting BizTalk solutions, you often make the tradeoff between something that is either (a) quite complex, decoupled and easier to scale and change, or (b) something a bit more rigid but simpler to build, deploy and maintain. How do you find the right balance between those extremes and deliver a project on time and architected the “right” way for the customer?
A: By their nature integration projects can be really varied, and even seasoned veterans will come across scenarios which they haven’t seen before or a problem with many ways to solve it. I think its very helpful if you can be open-minded and able to step back and look at the problem from a number of angles, consider the solution from the perspective of all of your stakeholders. This should help you to evaluate the various options. Also one of my favorite things to do is to bounce the idea of some friends. You often see this on various news groups or email forums. I think sometimes people are afraid to do this, but you know, no one knows everything and people on these forums generally like to help each other out so its a very valuable resource to be able to bounce your thoughts off colleagues (especially if your project is small).
More specifically about Richard’s question I guess there is probably two camps on this, the first is “Keep it simple stupid”, and as a general rule if you do what you are required to do, do it well and do it cheaply then usually everyone will be happy. The problem with this comes when you can see there are things past the initial requirements which you should consider now or the longer term cost will be significantly higher. The one place you don’t want to go is where you end up lost in a world of your own complexity. I can think of a few occasions where I have seen solutions where the design had been taken to the complex extreme. While designing or coding, if you can teach yourself to regularly take a step away from your work and ask yourself “What is it that I’m trying to do” or to explain things to a colleague you will be surprised how many times you can save yourself a lot of headaches later.
I think one of the real strengths of BizTalk as a product is that it lets you have a lot of this flexibility without too much work compared to non BizTalk based approaches. I think in the current economic climate it is more difficult to convince a customer about the more complex decoupled approaches when they cant clearly and immediately see benefits from it. Most organizations are interested in cost and often the simpler solution is perceived to be the cheapest. The reality is that because BizTalk has things like the pub/sub model, BRE, ESB Guidance, etc it means you can deal with complexity and decoupling and scaling without it actually getting too complex. To give you a recent and simple example of this, one of my customers wanted to have a quick and simple way of publishing some events to a B2B partner from a LOB application. Without going into too much detail this was really easy to do, but the fact that it was based on BizTalk meant the decoupling offered by subscriptions allowed us to reuse this process three more times to publish events to different business partners in different formats over different protocols. This was something the customer hadn’t even thought about initially.
I think on this question there is also the risk factor to consider, when you go for the more complex solution the perceived risk of things going wrong is higher which tends to turn some people away from the approach, however this is where we go back to the earlier question about testing and development processes. If you can be confident in delivering something which is of high quality then you can be more confident in delivering something which is more complex.
Q [stupid question]: As we finish up the holiday season, I get my yearly reminder that I am utterly and completely incompetent at wrapping gifts. I usually end these nightmarish sessions completely hairless and missing a pint of blood. What is an example of something you can do, but are terrible at, and how can you correct this personal flaw?
A: I feel your pain on the gift wrapping front (literally). I guess anyone who has read this far will appreciate one of my flaws is that I can go on a bit, hope some of it was interesting enough!
I think the things that I like to think I can do, but in reality I’d have to admit I am terrible at are Cooking and DIY. Both are easily corrected by getting other people to do them, but saying as this will be the first interview of the new year I guess its fitting that I should make a new years resolution so I’ll plan to do something about one of them. Maybe take a cooking class.
Oh did I mention another flaw is that I’m not too good at keeping new years resolutions.
Thanks to Mike for taking the time to entertain us and provide some great insights.
Richard Seroter's Architecture Musings 