TDIing out loud, ok SDIing as well

Ramblings on the paradigm-shift that is TDI.

Monday, October 4, 2021

As Eisenhower said, Plans are Useless soon as the first shot is fired. However, the art of planning is invaluable. In other words, plan for change and be ready to change your plans. Repeatedly. This be the foundation of an agile approach to solution development.

I agree with Ken Schwaber in that many agile methodologies do not feel very agile. Some major contenders are thinly veiled command-and-control frameworks in which you entrust your development effort. This kind of regimented approach is seen as a less risky flavour of agile for newcomers to the game. And it feels familiar to those who followed the phase-gate approach to development which was dominant in the last millenia.

Teams should spend focus and energy on meeting Sprint goals, as opposed to rigid adherence to, and maintenance of the process. And sure it’s easy for me to say. Over the past twenty years I’ve had the pleasure of working in dozens of teams, and most of them were comfortably small. Single-pizza sized. However, I have also clocked hours in larger projects and participated in dutiful loyalty to formally defined tasks and metrics gathering, all the while as velocity floundered. With few degrees of freedom to analyze and optimize the process itself, we lacked the tools to improve - at least during my residency.

In my experience, agility that matters requires embracing change. Enabling and amplifying feedback, and then exploiting this to drive velocity and quality. Which is why I am such a fan of Scrum. As Jeff Sutherland says in his seminal book, Scrum is ‘akin to evolutionary, adaptive, and self-correcting systems’. The founders of Scrum live by this ethos of relentless improvement and the Guide itself weighs in at 13 pages! It represents the essence of agility.

What I am trying to impress on my fellow practitioners in the elusive art of agile solutioning is to keep the Agile Manifesto close to your hearts, regardless of the methodology your dev org follows. Strive for the three pillars of Scrum: transparency, inspection and adaption - of the product and the practice. It’s too easy to lose sight of the forest by focusing too much on individual shrubberies

Sunday, December 13, 2020

Agile is as Agile does... paraphrase Forest Gump. TDI (aka SDI) is an extraordinarily agile platform for exploration, prototyping and crafting enterprise-strength solutions for data movement and services. However, using it or any other tool does not an agile developer make. Agile development is all about mindset and culture rather than processes and tools. In this age of industrialized and weaponized Agile (the noun vs. the adjective, as opined by thought leaders like Ken Schwaber and Dave Snowden) that perspective can be lost.

But of course, seeing the world through TDI-colored glasses mean that my view is indeed a bit colored...

TDI is an excellent platform for agile development work, also in teams. I've worked in several projects where multiple developers worked on the same TDI projects. However, sharing the source code (ALs, Components, Scripts, etc.) using something like git requires a little forethought and setup. The first step is good organization of both source and deployment assets.

As I've noted before, I organize projects in a particular way that has served me well for years:
  • A Project Folder (the one that Eclipse gives you in your workspace and that shows up in the CE). In general, apart from running git from this folder, I tend to leave everything being managed by Eclipse alone.
  • And a Solution Folder (with the same name as the Project itself and found in the Solution Directory). 
  • Furthermore, all filepaths in the solution are relative and reference files in the Solution Folder, or its sub-directories. Filepaths also have only forward slashes instead of backslashes.
The advantage of this last item is that solutions run equally well on Linux and Windows, and that you can deploy the solution to a new server by first zipping down the Solution Folder and then unzipping it into the Solution Directory of the target TDI server. Of course, along with any CustomJars files and folders your solution depends on.

As you may have gathered from my description above, there needs to be two git repositories: one for the Project Folder and  one for the Solution Folder. The Project Folder is the source while the Solution Folder holds the deployment assets, including properties and other support files and folders. Which also means all Property Store filepaths should be relative (and with forward slashes). As noted above, you may have custom jars for your solution. Simply drop them all into a folder ,  e.g. CustomJars, in the Solution Directory. You let TDI know about this folder via the property in which is found in your Solution Directory. Be sure and make this a relative path too.

This is the first step. Then comes the tricky bit.

Since TDI source files (*.assemblyline, *.connector. etc.) are all XML encoded, merging changes when two or more people edit the same source asset can be a challenge. For one thing, there are plenty of XML tags in these files that are only for internal use, like <ModTime>. So you end up having go through the files, comparing known tags and script snippets. Not ideal.

Which is why we kept to a strict git regime: push to the trunk (i.e. master, with no branches) using pull requests for peer review, and agreement on which files we each were working on. Not ideal, but until we can get a VSCode extension that handles this for us, it's the best you can do. Of course, editors like VSCode make it easier to compare changes and accept/reject as desired.

Once source management (and sharing) is organized, it then comes down to organizing work. Here is where Scrum, the brainchild of Ken Schwaber and Jeff Sutherland, both Agile Manifesto signatories, comes in.

Their original vision of Scrum is as a flexible, adjust-as-you-need methodology that really dictates only a few things:

  1. Cross-functional, empowered teams
  2. Short work cycles with clearly defined outputs
  3. Open and continuous communication
The first point is to limit wait times due to expertise or authority lacking in the team. The second item is so that measurable results are continually produced. And finally, the last point is to make sure that a) any blockers can be quickly swarmed on and dealt with, and b) everyone in the team knows what is happening, current priorities and why.

Now you might be saying, hey wait, traditionally practiced Scrum also defines distinct rolls like product owner, dev team and Scrum Master. These roles may be covered by team members, although for small teams they may necessarily be resources outside the team. If so then it is important to open lines of communication with the people performing these duties - and one that provides for informal comms if possible. 

Most of the TDI work I've done over the past couple of decades has been with one to two other individuals. So to augment our team, we enlisted someone with both an understanding of the requirements, and the ability to prioritize these. Typically an architect or project manager, who then becomes our Product Owner. As to the Scrum Master, I've provided agile coaching while we all shared the admin work.

And finally, we build a relationship with the person or people responsible for operating the solution once we deliver it. This gives us DevOps insights into how we make the final solution easier to (re)install (e.g. Disaster Recover), manage (stop & restart) and monitor (logs, audits and other operational output).

Tuesday, December 1, 2020

How to turn security events from QRadar into self-healing actions on infrastructure

Here for your perusal is a self-contained solution that provides a service AL that listens for incoming requests coming from QRadar Event Rules. You write your own ALs to perform actions based on various events, using data shared by QRadar in the event action request JSON. Note that this is part of the Guardium bundle, leveraging it to automatically perform reconfiguration, like locking suspicious user credentials, or closing off access to a resource pending further analysis.


Thursday, January 23, 2020

SDI, TDI, what's in a name

When IBM acquired the integration powertool back in 2002 it was called 'IBM Data Integrator'. Then after a bit of political squabbling, it was moved to the Tivoli brand and renamed 'Tivoli Directory Integrator'. Now, after its move to the Security brand a few years back, the name became 'Security Directory Integrator'.

I just think of it as 'Integrator', although my fingers still type 'TDI'. Old habits. And it is still being used for a wide variety of scenarios from cloud application integration to infrastructure rewiring.

So don't let the name fool you.

Monday, June 17, 2019

How To Ask Smart Questions

Although this article is particularly about asking hackers there are some universally relevant pearls here that are ring particularly true today:

It's easiest to go for the quick fix when it comes to information gathering. It's apparent in the alarming number of people who's primary news source is social media, and it's highlighted nicely in this article about how Google Maps is making us dumber:

In particular, it's about exercising the gray cells to uncover the desired knowledge. This list of steps from the first article above is by no means exhaustive:

--- excerpt

Before You Ask

Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
  1. Try to find an answer by searching the archives of the forum or mailing list you plan to post to.
  2. Try to find an answer by searching the Web.
  3. Try to find an answer by reading the manual.
  4. Try to find an answer by reading a FAQ.
  5. Try to find an answer by inspection or experimentation.
  6. Try to find an answer by asking a skilled friend.
  7. If you're a programmer, try to find an answer by reading the source code.

Of course, sometimes speed is critical. But a little forethought and investigation will help make your question easier and faster to answer.

And since I see the world through TDI-colored specs, I going to add that

  • You include 'java' to any searches involving TDI research and troubleshooting (step 2)
  • The AL Debugger is a great tool for step 5
  • The TDI user forum is where many of your skilled friends can be found* :)

*Link here:

Tuesday, June 4, 2019

SDI/TDI as a Windows Service

NOTE: You must remember to copy the ibmdiservice.exe and ibmdiservice.props files from the <InstallDir>\win32_service folder to your Solution Directory (soldir) before you run the service installer.

It is a common mistake to run the service installer from the wrong folder - i.e. not your soldir. Often this is done from <InstallDir>\win32_service where the .exe and .props files are found.

And if you don't know what the soldir means to an SDI/TDI Server, please have a look here: for this and much more Integrator Know-how you should know.

Note also that you can fire up the Config Editor (CE), ensure the 'Default' Server document points to the same port, install folder and solution directory, and monitor and operate the running server.

Tuesday, September 25, 2018

Thinking about agility

My favorite agile tool is TDI (and please forgive an old man for having trouble shifting to 'SDI'). Not only can I whip together integration service prototypes faster than anything I can do in Java (Spring), or Python or TurboPascal, but I can also build Ops features this way. Monitoring and remote control (pause, restart, failover/failback) for enabling auto-healing, or at least making the solution cheaper to own. As you know, the cost of building a service can quickly be dwarfed by the cost of owning that service over time.

My recent history as a GBS consultant has made DevOps a focus of my job and I have been applying modern tools and techniques to TDI. This includes using git for source management, which ties nicely into CI/CD pipelines. Jason, of Adventures in TDI and TDI support fame, helped me to install eGit in my SDI CE both on Windows and Linux. Git was created by Linux Torvald who gave us Linux, so it's really easy, fast and a de facto standard.

Of course, to build a DevOps pipeline I needed a 'TDI compiler' to turn the TDI workspace Project folder structure and files into the one big Config xml file that the TDI Server needs. So I wrote this Python script. You run it from a command line like this:

    python -p <Project path>

With these optional parameters:

     -h                 Help & usage instructions
     -v                 Display version
     -c <path>     Write the config to the file specified by <path>
     -n <name>   Set the Solution Instance name (web api) to <name>
     -o                 If present, overwrite the resulting config file

You can grab the script by installing the git commandline and typing someplace where you want the files downloaded:

       git clone

Once this was working I focused on Dockerizing a TDI solution. This was pretty simple to do, so I first made a default TDI (SDI) image and then can roll new Dockerfiles to create images based on specific solutions (configs). Then I pushed this up to a Kubernetes cluster and tested it. Pretty simple and the answer to HA and scalability, if you're willing to design for componentization.

Now my next step is to tie this altogether in a pipeline for continuous integration and delivery. Thinking of using Jenkins since I have used it before and have lots of old Jenkinsfiles to copy/paste from. Once I have everything working I though I might quick video.

Sound like a plan? Interested? I know that TDI'ers are often engaged in quick one-off integrations, like security Adapters for ISIM or IGI or PIM. However, for those delivering services (infrastructure wiring) I would think DevOps is important. I look forward to hearing back from y'all :)