MS BizTalk and Enterprise Application Integration

I have been working with BizTalk (with no formal training) quite extensively since last few weeks. We are using this as the middleware for an EAI project. Some interesting things I noticed about it are:

• It looks simple
• Looks easy to use
• Easy to create simple solutions
• Some what complicated to actually make the developed solutions work

The main goal for a middleware in this case is to implement business processes through orchestrations (guess that is the purporse..right?) and transform incoming some vendor application data formats to a standarized data format for the message bus developed specifically for the Enterprise Application Integration Architecture. Once it comes to web services it get a little more complicated, but just picking up a file and routing it through multiple business process based on the content (content based routing) is actually not very difficult. BizTalk is solution development is very tightly integrated with .Net and its very easy to implement .Net classes (specifically XML) in the solutions. You use VS.Net 2005 to develop the solutions by using BizTalk SDK and projects. This compiles into a dll and you can either deploy the solution from VS or just create an application in the BizTalk Administration console and bring in the dll. I can go into details if some one wants that. This is how a simple biztalk orchestration looks like (this is from a msdn sample project):

BizTalk only Talks XML ;-) so you need to learn that in order to actually develop a standarized communication infrastructure for the EAI (i.e. the Communication Bus). From there on its should be down hill. You do need to understand how to design the orchestrations, I would highly recommend some kind of business case -> UML -> Technical Structure kind of approach. Lots of discussions and then ensuring how you will bring in the "Incoming" messages and where to i.e. Message Box or Web Services and how/where these will be routed to i.e. SOAP over http or handed over to another orchestration etc. You can download BizTalk sample from: http://msdn2.microsoft.com/en-us/biztalk/aa937647.aspx. Of course you will find tons of information and help on BizTalk over the internet. Just Google!

I will add a lot more on this i.e. EAI soon...so till then CHAO!!

Development Intellegence

Sorry for being so lazy...but here is the document that I was referring to in my earlier post about development intellegence: http://bhm-tc.org/Documents/developmental-intellligence.pdf. I will write more about this and other software engineering processor development models.

Visibility in Software Development Projects..... Invisible?

I've always thought of how we can achieve visibility in software projects? Its nice to use PM, Defect Management, Issue tracking tools and of course, (all time favorite) excel spread sheets but once it comes down to managing all of these together we are talking about either lots of manual labor or high cost software. Something like MS Team Foundation Server or Borland's Star Team. The cost for these tools is enormous. If you have that kind of money, get them but remember its not the right kind of tools that get the job done, its the right use of right kind of tools that produce results.

Now, if you don't have that kind of money here is something that I have been working on for some time now. I call it "DBA2" i.e. Dynamic Business Management Application Architecture Framework. The framework is a combination of Business Processes and software's back end technical architecture. Architecture and Design has always been very interesting for me. For an architect I think its important to understand the different scenarios while you work out the technical requirements part of the system. One has to understand the bridge between the functional and technical requirements. Architects have to understand programming, then again its important for an architect to understand cross platform or platform independent semantics as well. Its important for an architect to think visually, again be able to map that bridge from functional aspects of the system to the technical details. Having the ability to work productively with the programmers is good but be able to work with analysts and visually define the system before you get with the programmers is also important.

Now to relate that DBA2 (I mentioned earlier) with the business process and functional units in a business: It combines intelligent software units to the status, messaging and application behavior aspects. This helps in communication between units. The basic concept is that each unit we design has the ability to intelligently survive on its own and be able to manage its functions without external help but for a stable system it needs the ability to work with other units, that is where status, messaging and behavior comes in. The smallest unit of the framework is called an "element", which combine together to make an "Entity" which from the functional aspect relates to a business or sub-business process and so on and so forth. There are stages that are the tiers for the framework etc.

You can read the paper here or http://www.bhm-tc.org/Documents/DBA2.pdf.

The framework allows the architects and even the developers to not only focus on the specific tasks at hand but at the same time be able to look at the bigger picture during the development of the software thus giving full visibility over defect management, QA and timelines. If you know where you are going...you will get there in time and with minimum problems...right???

So lets discuss this framework if you have time!!

Like always thanks for looking at the bridge between technology and business.

Software Guy!