Saturday, July 28, 2007

About this Blog

Okay, I deleted my account by mistake... The blog is still there but I can't get to it now. Yes, I know...blogger support is the most complicated and unavailable as I have experienced. I emailed them and posted messages but no response. So I created a new blog and copied all from there to this blog. Sorry for any inconvinience. I will of course get something of my own soon and put all this there. Thanks for all your emails and support!

The old blog is at: www.moiz-ahmed.blogspot.com

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.

Enterprise Application Integration and SDLC Processes

Okay, I finally have some time to write today, I have been working on Enterprise Application Integration Project with SOA. Its been an interesting journey though, we looked deeply into MS BizTalk and how it will help us manage the Enterprise Service Bus. I think the main components of an EAI is the messaging middle tier and how it handles communication with subscribing components of the EAI. The interesting part is that we have so many of these available that it sometimes becomes difficult to select the one you really need. Also with so many of middle tiers around, each vendor has developed their own terminology - another problem?? Of Course, how do you standardize industry wise (I will discuss that in a later post). Now I came across an interesting concept from Borland the other day. As we all know Borland had developed its Software Engnieering Process and Development Life Cycle management tools division and is focusing on marketing those tools now. I read an article that decribes DI (Development Intellegent) i.e how to gather statistical data from the development life cycle, create trends and use that to maintain and improve data i.e. create intellegent statistical model to improve upon the efficiency of delivery of your software projects. I will post or link to the document here as soon as I figure out how. I will be leaving for Philly in a day or two for a client meeting but will do this as soon as I come back.

Here we go!!

Hello Friends,

I was thinking of doing this for quite somtime now (well start blogging...what else?), but the new job, move to the lone star state (city of Houston), selling a house and what not delayed the plans. I am still waiting on my movers....well what can I say...I will NEVER even think about moving with this company again. Anyways..where were we??Oh yeah! so here I am, this is the first blog of hopefully many more to come. What are these about? Well we will have stuff about Software Engineering Processes, Requirement Analysis, Delivery/Implementation, PM and Published Articles, Presentations, Research Documents etc. I will also try and write something about Business Processes(Re-Engineering), Software Engineering and Aligning IT with Business Strategy. So stay Tuned ;)