Stop it! Or you’ll end up buried in a box!

You wouldn't believe the number of people who do not understand this the first time they hear them.

Scientific collaborator for UMons Polytech for one more year

I've been recognized as an official scientific collaborator for the University of Mons for 2012-2013. That's pretty nice of them. I'd like to do some GPGPU with Pharo Smalltalk projects with students then.

Intro to Datapower at #IBM #ICTY

Datapower is the IBM Websphere Connectivity and Integration Appliance. Basically, this is full of custom ASICs and stuff and is fast, easy to configure and not prone to all crap that happens to standard boxes. Datapower was a company in its own right and was acquired by IBM.

How special is Datapower On the feature set, it is special:

  • Simple architecture: firmware and purpose built hardware. (firmware is often updated to keep up with novelties)
  • Delivered from the factory with everything you ned to connect to the network and start working
  • All computationally-significant components are sealed with temper proof casing (chips, memory, board and card, signed flash file system). Superfast parsing and crypto engines. Truly in a league of its own. Does TripleDES, AES, RSA1.5 etc.

How does Datapower fares on the market? Pretty well actually. " of the best selling Websphere products since the acquisition of Datapower inc in 2005."

Well, what's in a name? From 2002 to 2012.

XA35-XS50-Xi50-WTX-XB60-Blade-XI52/XB62/XE82-XG45 The firmware is developer since 10 years already. Hopefully, this is now pretty good. JSON is in there now. Phew, enough of XML 🙂

Usage areas and users Various patterns of usage where

sensitive information is transported over the internet. * Government (Defense, Agencies and ministries) * Banking (Encrypting card numbers) * Insurance * Retail, Utilities, Power, Oil and Gas Close to 1000 worldwide installations and growing.

What were the classical business cases? Classic SOA business case, with complex SOAP structures. And this means a huge computing effort... crypto, signing, auth, filtering, SLA checking, alerts... All in a single box. How sweet. So, it saves money and headaches. But messenging has evolved a lot (with mobile coming on the scene).

New use cases

  • Provide secure data communication across channels and protect them (who uses our services, to what extent, limit this leeches, limit traffic to guarantee QoS)
  • Protection from SQL injection (don't be sub-optimal in its performance), XSS
  • Consolidate (Transformation, Protocol mediation, Routing, Caching)
  • Manage (simple configuration, policy driven setup, centralized governance with WSRR links) It also is very suited to the Internet of Things era. It can swallow the storm. Without blinking an eye. Well, a led or two... Support for mobile devices call for special care on security. Datapower to the rescue here. The Datapower is then living in the DMZ. In the DMZ here are the rolls to take:
  1. Secure gateway (web services, web apps)
  2. B2B gateway (EDI aware)
  3. Edge optimization
  4. Side cache In the trusted domain, here are some more:

  5. Internal security point

  6. Enterprise Service Bus
  7. Runtime SOA governance
  8. Web Service Management
  9. Legacy integration Each of these roles are best served with a special flavor of the Datapower brand. Let's say that the next feature will be to brew coffee and sing God Save the Queen. Quite a few things in there indeed.

And ideal beast for deployment into less than fully trusted network (savage gardens, I'd say) Useful due to:

  1. Common criteria compliance to EAL4 and FIPS 140-2 Level 3
  2. Tamper proof box
  3. Signed and encrypted file system

As a secure gateway

Some physical characteristics 1 U form factor, 4x1Gbps Ethernet port, 2x10Gbps ports.

Feature set focus Proxying and enforcement Protocol support: HTTP(S), WMQ, Websphere JMS, FTP(S) Format support: XML, SOAP, JSON, PKCS7 (option) Transformation engines: XSLT, DataGlue - WTX/FFD (option) (use Validation maps and Transformation maps) Using WTX Design Studio (Eclipse based) Does things like:

  • JSON outside, SOAP inside.
  • Disallow some countries to see some content before they are allowed to

As a B2B gateway

Some physical characteristics 2U form factor 8x1Gbps 2x10Gbps More memory, more storage

Feature set focus

  • Partner management functions
  • Enhanced QoS
  • Additonal protocols
  • Addition formats
  • Additional transformation engines
  • And including all of the Security Gateway base

Popular uses in the internal side of business as well... Simplified lower-touch maintenance (1-2 upgrades of firmware per year) Fast, less expensive deployment (config only, delivery to production in less than a month)

As an ESB and Legacy enablement point

  • A drop-in ESB. Less headaches!
  • Easily service-enable legacy apps
  • ...

As an elastic caching within infrastructure Meaning? Meaning it offloads processing from the backend side.

How to do this?

  • Optimize response time (cache response data)
  • Reduce server load (cache response data)

There are other form factors as well In the blade form, in need of fitting that in chassis (XI50b "blade") And for Systemz. XI50z

What's new in 2012? Datapower Firmware V5.0 highlights:

  • OAuth support
  • OAuth scenarios (3-legged, 2-legged)
  • SLA Enforcement and SLDs (Service Level Defintions, synchronized with WSRR) New WS-Proxy feature with WS-Mediation Policy. Configuration only. Great! Works! (We have integrated this, with V5 and WSRR 8, alerts also go to ITCAM for SOA in Tivoli with the Datapower agent).

  • Application optimization options, allowing to self balance across a cluster of appliances.

  • Application aware intelligent load distribution

The Websphere Applicance Management Center (WAMC)

  • multi box management in a single place.

Check the resources

  • (
  • youtube has some


  • Appliance architectural paterns
  • The programmatic management interface Good presentation on the features. A bid sad to have had to rush at the end on the new feature set.

The future of #SOA at #ibm #icty 2012 with Gerry Keilly

The content in here is my own set of notes and not Gerry's words Back to the four trends. Mobile. Cloud. Big data. Social.
  • SOA is built upon clean design principles.
  • All workloads are not created equally.
  • Historical workloads are pretty much predictable.
Social and mobile are different beasts! Snowstorms! Reactions! Checks! Fast! Often! Kill the API. Need some cache and policy in here... Volume and speed of interactions are impredcitable events. Peak management and buffering are the new skills. Yeah! Sweet. Bare metal and instrumentation are coming back! Expose your enterprise. Expose your flaws. And the crowd is not going to let you breathe for long. As we do have hybrid deploypment, cloud and on premises, new skills are needed too.

Connectivity and integration technologies

Universal connectivity. We are back to not so reliable connections. In fact, back to the same kind of problems of the good old days, only larger and more acute. scale matters.

Websphere MQ 7.5

Integration with MFT. Build an integrated capability for a rich capability layer that will stand the requirements for the upcoming wave! Ture indeed. I am now working with that tech. It rules, period. WMQ telemetry. Millions of connections. Price lowered. WMQ AMS. MQTT brings MQ into the mobile space. TT for telemetry transport. So, moving to open source for MQTT for ensring adoption. Good idea Gerry. Gain reliable delivery over fragile connections. 3G anyone? Leverage information provided by mobile devices. Ease of integration with enterprise applications. Build a smarter planet with messaging optimized for smart sensors and telemetry devices. ... With MQ Telemetry. Monitor a peacemaker over the network! Cool use case. Put a lightweight MQTT client on any device. Smartmeters, gas pumps, fridges... Exciting!

Cloud connectivity deployments spanning on and off premise

  • connecting to cloud
  • connectivity between clouds
  • Location independance. Switch where the connection is goig under the covers.

a word on APIs

Businesses opening up APIs is a game changer if you do it right. And kill your business if you get it wrong. Damn right! Apigee is cool btw, check it out! Connect to a broad application developer community. Extend your core services with an ability to build capability internally. BTW Salesforce has a huge event these days. And a huge huge huge attendance! not having an API today is like not having a website in the 90's I love that line! Your API is an extension of your brand. You can ruin your brand by having this wrong. Your API extends the value of your brand.

Websphere CastIron Live.

Enabling rapid and trusted entry into the web economy. Expose, manage, control, run analytics on your services. Create > Socialize > Manage 90 day trial. Gotta give it a shot! Too bad it doesnt lists Belgium in the country list...

Websphere Message Broker v8

Powerful beast. I testify from real world exposure. This thing pumps out an awesome amount of messages per second with an incredibly small number of CPUs. Extreme scale in WMB: cross broker caching. Agregation. Well, a killer. Period.

Every project and everyprocess needs a proven platform

Yeah sure. But startups go node.js on V8.

A new breed of systems

Systems with integrated expertiseand built for cloud. Okay, that is the integrated capability. Great but the string attached is vendor lock in. No matter how good the vendor. That is where you'll need people understanding all of this in you company. Who is pointing at me here? Just joking. Half joking that is... Well, IBM has the ability to deliver for sure. Are clients going to be up to the reauired maturity level to exploit the tech properly? Will the culture be able to swallow that huge pill? And nit feel obsolete in the process? People are what makes or breaks things indeed! Extend > Transact > Optimize

Things do change. But fundamentals do not.

  1. Right design practices
  2. Well managed, well governed services
Embarking with IBM may be the smarter choice. provided you have the money of course.

Mobile strategy for #ibm at #icty

Mobile strategy

  • Extend and transform for mobile
  • Mananage and secure
  • Build and connect

Top challenges

Fragmentation Speed of dev Connect backend Securely


IBM Worklight! Acquired by IBM.

Why cross platform?

The mobile world is in flux. What about 2015?

Spectrum of choices: dimensions

Richness, portability, TCO Hybrid apps with nativemodules. Hey, Monkey is right! HTML5, JQuery, dojo, Cordova, Sencha Ability to track all of your stores at once: worklight starter and catalog, also ability to disable versions. Asking for upgrades. Ability to have a grip on how apps are used by the users.
  • Protecting data on the device
  • Enforce security updates
  • Robust auth*
  • App security
Open technologies: skills are available.


Websphere cast iron hypervisor edition appliance

Create fast integrations with business back end systems. TTM is important indeed.

The mobile worker movement

Mobile workers get more done. ROWE. The interesting device sharing situation. Amgry birds meets your banking account... Corporate data leakage. Dropbox anyone?

Device management

Policies and enforcmemt. Black and white listing of appa Ibm endpoint manager to the recue.

Ibm mobile foundation v5.0

All of the above products. Plus some services of course!

Horizon : IOT - internet of things

Dogs and cows have an IP. Trash the manuals with NFC and your mobile phone. Neat! Update your coffee machine, get a virus in the process,yay! The story of mobile will turn into the story of everyhing everywhere all the time!

Mobile as a differentiator

Faster time to value


  • Open
  • Governed
  • Integral
Pretty cool prez. Bringing some key points home about the monile channel.

How to structure our workflow when working in an Agile way for a significant project?

Spamcast 205 - September 2012 Column Transcript Follow me on Twitter: @philippeback ( Hello everyone, this is Philippe Back and I'll be discussing how we came up with a way to structure our workflow in a project where I was a project lead (as this involved two firms, we were two at the helm actually). On the methodological front, we were supposed to use an Agile approach. And a tool. Well, okay, agile and a tool. I have been saying it for ages, say more than 10 years now, I am all for people over processes and tools.

Tools to the rescue

But at one point, people do love to have a tool to help them track their work. Especially when it becomes quite complex, full of little things to remember, and with interdependencies between people that are scattered around quite a number of locations, some very remote. Add to the mix that some resources in a project can become quite hard to reach because they do have a scarce skill, and that fact alone leads to them being unable to be around all the time. In such a situation, so much for post-it notes. So much for a whatever-kanban-or-anything board on the wall. It just isn't sufficient to deal with the situation. There are tools to help here, our happens to be IBM Rational Team Concert. A fine tool if you ask me. Especially when you go through the massive learning curve that comes with it. Let me digress here. It is important to have a tool to help and the tool has a massive learning curve. Given the typical project setup and constraints, nobody in its right mind would go for a massive learning curve when a deadline is near.

Process practicioners and process engineers

That's why we must distinguish process engineers from process practitioners. Process practitioners do not have to care about all the nitty gritty details of the bowels of the beast. They just need a clean workflow that they can participate to. A way to work out their tasks, hopefully in an oranized way that makes sense. And a workflow that will help them. Not turn them into bureaucrats. Process engineers must master the tooling. But you do not need a ton of them. At the same time, I guess we do not need the kind of process engineer who would rather be splitting hairs in 4096 and come up with a process template so convoluted that anyone looking at it would either run for the bar or the door (depending of which was near at the time of that vision from hell). Long story short, here are two key factors for success:
  1. Process practitioners who are convinced that the thing actually helps them
  2. A process engineer (that should be waay enough with solid expertise in keeping things simple and effective (we'll leave efficient later as an efficient ineffective approach kind of leaves me cold).

Structuring 101

Let's get back to our structuring thing. In the agile "ontology" (oops, sorry, one more buzzword, so let say "vocabulary" or "agile-talk", there are several interesting structuring concepts:
  1. Product
  2. Iteration (aka Sprint, well, a Timebox will do anyway)
  3. Release
  4. Backlog
  5. Impediments, blocking factors (I kind of like the impediment thing tough)
  6. Defects
  7. Tasks (almost forgot those, all this management stuff is really growing on us at times)
  8. Stories
  9. Epics
All of these bits and pieces are nice. But actually, they aren't helping much with structuring the work. I kind of like Epics. So much that I used them as the way to represent my PBS (for Product Breakdown Structure). Maybe you know the GDPM (Goal Directed Project Management) method. It is kind of neat. There is one single structuring concept that hit home with me for all those years. The notion that when thinking about a project, one must look at three specific things (and no, I am not talking about the PSO (People, Systems, Organization) acronym). These are:
  1. Enabling Factors
  2. Core Product
  3. Support Functions
What are these in some more details? Well, "Enabling Factors" are the elements that you need to have in place so that you can actually work. No team, no work. No systems, no work. No office space, no work. You see the thing. Under that label, we also find silly things like "Access to the facility is provided". Some learning about unknown areas also do lie under those "Enabling factors". Make no mistake, those aren't all have to be put all upfront in the first iteration of your project. Quite a bunch of them should be there actually but well, not all of them. And "Enabling Factors" is an Epic for me. Then we ge the "Core Product" which is what you are trying to build in the first place. There we have things like Core-Platform, Core-Clients, Core-AccessManagement, Core-Mechanisms, Core-Flows, Core-Monitoring, Core-Reporting. I like have all those things as "Epics" as well, all under one parent "Epic" named "Core-Product". The children of the Core-Product Epic are more often than not structured like what you have as architectural building blocks in you high level design. Don't think of them as cast in stone, but rather as a guide to help in structuring the Core Product. As we learn more by doing, the structure may change. No big deal if you work with a decent enough tool that will allow us to restructure dynamically on the go. And, last but not least, we get the "Support Functions" part. Oops, pardon me, the "Support Functions" Epic. And this one is supposed to be the home for all things preventing the core product from suffering too much decay as it is built and operated. Typical entries include: "Backup is operational", "Source is managed in the source control system", "Bugs are reported", "Estimates are provided". Well, I guess you can picture that. All of this structure of epics provides a quite standard layout into which one can hook the myriad of stories that are in the backlog. Epics One thing is for sure, it is that an Epic is not something that will be confused with a task. An Epic labeled "Configure a queue in the X queue manager" is sending chills down my spine. "The queuing system is configuredas specified" is already better. The fact that it could be a story and not an epic is another matter. Let's now focus on "Tasks". Indeed, there is work to be done, right?

Structuring tasks

Now, we have this set of "tasks" that people will have to carry to reach the destination. What I see is that a lot of times, we do get silly tasks, labeled in wild ways. And that doesn't help in getting a clear picture. I do hate a "fog of war" when it comes to software projects. So, how to write tasks that do hold water? Consider this: You always have three kinds of tasks: Design tasks, Implementation tasks, and Handover tasks. enter image description here To get something working, you need to think it through, get a pass at actually building it, and once done, ensure that what you produced as output or value gets transferred decently to whoever needs it further in the stream. And then they can be pulled by the team members. Well, at the beginning, they may need a little gentle push to get started. And then these can be estimated. And performed. And given actual values. And velocity computed. And a realistic, understandable burndown chart produced.

A little recap

I guess our plate is full for this installment. Let's summarize:
  1. In order to be effective, we need some structure
  2. The basic tenets of Agile are all fine but we need some more structuring concepts. We can get those from Epics, themselves broken down in further epics.
  3. The three top level epics are: Enabling factors, Core-Product, and Support Functions
  4. Get the core product Epic broken down in sub-epics, one for each architectural building block, and one for key mechanims you need.
  5. Get stories out of the backlog and stick them under that top-level, PBS-like structure.
  6. Put tasks in there, along the lines of Design-related tasks, Implementation tasks, and Hand over tasks.
What not to do... Yes, it is important to remember that as well. So, what not to do:
  1. Do not ... Try to be complete up front. That is going to put you into a frozen state in no time.
  2. Do not ... Try to come up with a plan full of dependencies in all directions. A single parent connection from stories to epics and epics to parent epics will do.
  3. Do not ... Expect the team to make all of this happen on its own out of the blue. Get someone working on the structure and be ready to reorganize.
  4. Do not ... Expect to master all of this overnight. It took me years. I'd be glad you can do this in no time, but actually, that's not how it work. So, do not put that pressure on your team as well. Let the concepts permeate the thinking and be ready to reorganize mistakes like, every evening so that the structure is clean for the next day.


I hope you'll find something usable in all of this. Remember that a frame like the one we discussed allows the team to collaborate and transfer their energy and abilities into tangible resutls. A frame like the frame of a bike. A frame that frees you from trouble. Not to be confused by a frame that binds you into limits. But remember that with great power comes great responsibility. Act accordingly and refrain from too grandiose a plan for a single timebox. Reality always wins in the end anyway. See you next time. Bye! --Philippe