Enterprise IT migrations and/or transformation challenges

 Introduction

In my first blog entries I discussed the brave new ways of building mobile applications and in specific the use of cloud hosted technologies. 

As IT departments scramble shifting to Mobile/Cloud/Analytics technologies  and Dev-ops/Agile methodologies, it is very important to keep an eye on how to approach existing ecosystem with these changes, it is a great opportunity to revitalize IT teams, and they must become partners in the movement instead of being dragged along for the rough ride.

From Migration to Transformation.

For the past few decades and since the introduction of the PC, Change has been the only constant in IT, and it did come in Waves, Each wave provides quick cycles of change at first, then it matures, the cycles of change slow down until another wave hits and we repeat.

The PC was the first wave, the 'Killer App's coming fast and furious (remember Word Star ?), Once DOS matured and slowed down the GUI wave came, Followed by the 'Internet' wave and its sibling, the "Internet Application" wave and once those matured and the cycle of development slowed down, the Mobile App wave came.

The mobile App wave is still raging with cycles of change, expect this to cool down sometime in the near future only to be followed by the Internet of things , wearable gear waves, apps every where waves.

 Every wave 'cycle' brings with it a 'Migration',  Enterprises know very well how painful those have been and can still be in the future, but they also know the benefits of them, and the danger of not doing it at the right time.

I have seen 4 types of Migrations and/or Transformations in enterprises in the past decades.

Release Migration

This type of migration happens fast and often specially in the early days of a wave . Think J2EE release frequency in the early days of the 'online application' wave. (before it was JAVA2EE)  or think the insane amount of frameworks and languages for building mobile applications and dev-ops in the current mobile application wave.

Competitive Migration

Ahh , those were fun and they are usually heated at the early days of a wave where technology providers jostled for space in the emerging market, I do have fond memories of being the 'Websphere guy' in BEA weblogic (then) environments.

Technology Migration

This type of migration happens just before the previous two usually but it happens much less often (And we should thank the IT Gods for that).

They are usually chaotic, disruptive and painful. with many jobs lost, new jobs created and it carries a shift in IT department culture along (more on that below).

There was a threshold where mainframe 'screen scraping' just did not cut it and that good old trusted main frame application was going to be rewritten in JAVA (horror of all horrors).  people like myself try to blog easing the pain of people moving from one technology to another, but no matter what, there will be causalities on both the department and personal levels.

Methodology Change

Methodology change is what happens when we moved from waterfall to Agile or when gigantic corporate like wall-mart moves to dev-ops.

These changes are equally painful to technology migrations and usually are a result of such moves.

The hallmark of Methodology change is "Resistance", it is almost impossible to do these changes by just issuing the 'top-down' commands, leadership from behind is a must, and building grassroots movement to support such change is key.

One of the best books I enjoyed reading that discuss only this type of change was Succeeding with Agile . it is a great read not on 'Agile' itself but rather on the group psychology of change and how it does impact organizations.

Key challenges for successful change.

From my work in many migrations through the years, if I am to choose the key challenges that IT managers need to keep an eye on it will be

Resistance to change 

This is just human nature, we are creatures of habit, and it professionals (the really good ones that you want to keep happy) identify on a personal level with their work, and change brings with it all types of insecurities and vulnerabilities.

Need for grass root 

this will go hand in hand with the resistance to change, the bigger the change , the more we will need to build grass roots, introduce change gradually and generally lead from behind.

Operation impact 

This is not "Operation Migration" but rather  the impact of this migration on the development/operation ecosystem. factors like bringing outside consultants to help the migration or promoting (related to grassroots factors above).

Skill gaps 

it is a fact of life, every change has a skill gap , not all skill gaps are created equal and to complicate matters , not all IT professionals respond to skill gaps equally.

Conclusion

There had never been a greater need for grassroots support and 'push from behind' type of migrations than these days, with modern technologies , the shift to cloud based and outsourcing of IT services, the focus is slowly shifting back to development and developers. and any IT migration and transformation process in the mobile/cloud/analytics era must take that into account.

IIB service development, pitfalls to avoid for new JAX-WS migrants.

DISCLAIMER : The following article discusses the behaviour of IIB 9.x , WMB 8.xx and prior releases, future IIB versions may (and most likely will) alter this behaviour. These are my personal views and do not represent IBM official position.

Introduction 

The more I work with IIB (and WMB), the more I feel it is the best ESB solution available from IBM and arguably from any provider (my bias notwithstanding), Developers moving from WESB to IIB will be pleased with the powerful range of features available and with the speed and ease of development.

However, a deeper understanding that the roots of IIB in MQ does make it a different environment than WESB which was a J2EE implementation, once you take that into consideration, migrating projects from WESB to IIB should be a much easier task.

The following blog entry should help you avoid some of the most common pitfalls and make your journey into WS development in IIB a lot more friendly.

You can find a quick tutorial on how to build IIB web services in my Worklight to IIB series here 

Use ESQL SET  with caution.

The order of elements in an XSD is important for XSD validation, breaking the order will lead to 'invalid xml'.

Take a look at this XSD and note the order of the elements.

When using the ESQL content assist you will see what you expect , the XSD is now part of the SOAP and XMLNC parsers.

The first thing to notice here is that content assist does not display elements in the same order as the XSD (this is a sign of things to come !).

In the code snippet above you also see the use of 'REFERENCE' which is a common technique to write neater source  ( and arguably faster  running code ).

Now we run the code and examine the resulting XML.

 

Now you get the picture, follow both the green arrows and the blue arrows and you will discover that the order of the XML output actually DEPENDS on the order of your code execution.

 That SOAP message that the code above generates is INVALID.

Conclusion.

• Your code must be written in the same order as the Original XSD.
• As you seen earlier the content assist is not in the right order so do not be fooled by that.
• If you plan to populate an XSD model through multiple steps (by using Environment or LocalEnvironment), you must make sure that all your code pieces execute in the same order every time.
• To guard against such mistakes and for peace of mind, I do highly recommend using a 'validate' node before you return your code (performance implications not withstanding).

Avoid the namespace mayhem.

"Mayhem : A state or situation of great confusion, disorder, trouble or destruction; chaos. " Wiktionary.

It is common for a single WSDL or even a single web service operation to have multiple namespaces in the sample I have here have two name spaces

• Service elements : "http://KLFSamples.ESB.WL/service/"
• Data elements     : "http://www.example.org/DB_Data"

Now look at this simple ESQL code that sets the SOAP response body to fixed values.

NOTE : The use of 'Reference' is highly recommended but you can not use a 'REFERENCE' until an element is created so a 'set' to an element in 'Person' object has to happen before I can reference it.  Personally I think it is one of those bugs that became a 'feature' as time went on. but I digress.

This previous code looks straight forward, but the XML generated in the SOAP message would carry a real "interesting" surprise to those used to  JAX-RPC and JAX-WS.

It seems that IIB 9.0 (Have not tested IIB10 yet) and Previous versions of WMB  have their own peculiar  way of adding and duplicating the same name space in multiple places.

The problem gets worse as the same 'NSx' could be defined with two different values in different places in the same SOAP message but within different hierarchical structures. 

So far, this is just an 'Ugly' message but not 'invalid'. But the problem will compound if you are actually writing into the input of a SOAPRequest node, and if that node is making a call into another IIB (or WMB) service those unexpected namespaces become impeded in the elements as they travel through the IIB engine, the reply from that SOAPRequest node will for sure carry an invalid XML and will probably break your flow. (do not ask me how I know ).

Solution 

Thanks to my friend and WMB Guru in ISSW Scott Rippley, the answer lies in the developer enumerating manually all Namespaces in their SOAP message, and inserting them all manually into the XMLNC or SOAP domain, thus forcing the parsers to use them and cleaning up output.

 The resulting SOAP message now will look like what you would have expected originally.

Technical Summary

• Keep track of all the name spaces used in your code abbreviated  by  NSxx as you use the ESQL content assist.
• Keep in mind those namespaces may span multiple files.
• Insert all of them using your own naming convention (NSyy) at the top of your SOAP message using the NamespaceDecl 
• Feel free to read more about it in the Infocenter topic here
• Remember to declare all your namespaces at the top of your code because .. well.. Order is important ! right ?.