Middleware – Keep it in the Middle!
*Disclaimer* – Notes in my blogs are about hypothetical scenarios. They do not directly or indirectly relate to any of my current or prior employers, or their clients.
Why this blog?
I quote you “Humans are unique among all animals because of their ability to learn from others mistakes. What’s even more unique is their reluctance to do so!”
What makes me qualified to comment on this subject?
I have been in Production support Environment for about 10 Years, at least 5 of which supporting SAP ECC. One of the project I have been involved with claims to be the largest SAP ECC implementation worldwide.
Target Audience, or Why should you spend time reading this?
This Blog is about how simple design elements can save hundreds of Hours, money and sometimes embarrassment from your Client or Customers in long run for Large scale IT projects’ maintenance. Often, IT projects are driven by urgency to deploy quickly, and fail to consider how it will be maintained for years to come.
Sometimes they include exotic design elements that are too difficult to sustain for many users across many locations. (May I quote an extreme imaginary scenario? “Don’t build a Unicorn if you don’t know how you would you feed it Gold crusted Diamond Pie everyday!”
All developers may find my comments useful. Technical Project leads, Architects, or Production support personals may find these more valuable than others.
Leave me Comments!
Your project situation may differ so my notes may not completely apply to you. However, I like good debates, and I am willing to listen!
If you don’t mind, please mention your production support experience if you have in your comments.
I hope you got the idea where I am going with this.
Let me start my first blog entry with the design elements that I have felt like are most controversial, and miss-understood.
Complex Design Elements in Middleware
I have come across enough examples of complex tasks that Middleware performs, essentially acting like End point, or transactional system with little end user awareness.
I suggest to
Give a lot of thoughts before implementing following elements in middleware.
1. Filtering – i.e. certain records are stopped, discarded, removed, at middleware.
2. Complex logic implementations (nested IFs, many lookups to either side)
3. Move some of the core processing to Middleware from Main system to save on resources
4. Business logic error handling
5. Complex substitutions (not one to one replaces)
1. I 100% agree that some of above may apply to some IT projects or interfaces, and that it can help ensure system is dedicated for core capability.
Possible Negative impacts:
1. End Users usually don’t have access to Middleware – Very few people can support issues inside Middleware! i.e. Business logic errors are now in hands of techie middleware guys to get involved with. Or that number of people who can support particular error scenarios is significantly reduced to handful of middleware monitors.
2. Some Middlewares don’t have detailed security restrictions (Compare to SAP ECC or other). Access to Middleware may mean access to all interfaces and logic.
3. Some Middlewares don’t have detailed logging capabilities (i.e. if records were dropped because they didn’t match certain conditions, how are you logging it?)
4. Some Middlewares don’t have advance programming language support – i.e. a simple if/else/case statements need creative thinking to implement.
5. You need Business logic experts monitoring Middleware logs and errors. You can’t rely on tier 1 or 2 folks which usually cost a lot less and are easier train. Analysis also takes more time because often Middlewares lack complex error analysis functionality and logs for research and Triage.
6. Some Middlewares may not have advance debugging tools. This will significantly affect ability to Identify complex urgent issues.
Possible issues you may encounter are:
1. Users may complain records are missing. However, they were rightfully dropped or manipulated at middleware without any visibility to End users. This will be particularly painful in earlier lifecycle of interfaces.
2. Users will often question reliability of the system overall since they don’t have visibility to middleware logic or logs.
3. Middleware matures faster, so new staff supporting middleware may not know all the ins and outs of a particular interface, thus needing more time to Triage. Lack of detailed logging may not help.
4. Middleware skillset sometime is hard to get, at least not as easy as ABAP!
Please review and comment! This is my first blog ever, so off course there are some learning opportunities here for me too!