Working for SDX (a.k.a. My latest project…)

Advertisement warning!

I’ve said it in an earlier post: I like working for SDX. In fact my work has become even more challenging due to a changed job description (with the unfortunate side effect that I have less time to spend on this blog). Anyway, we are looking for people (don’t look at the date of the post; if you are reading this in a year the statement will still be true). Well, here’s a short description of my latest project to give you an idea on some of the work we do for our customers…

I just completed a pilot study for one of our major customers, running about 3/4 of a year. Starting point was a system consisting of a non-trivial database and of two VB6/ActiveX/DHTML applications. Initially created a decade ago as replacement for a simple MS Access application, it had grown organically into a multi-purpose-application and a very vital, central data pool for “quite a few” stakeholders.

Since Microsoft has decommissioned VB6, the customer decided to do a VB6-to-.NET migration. My job as responsible architect was designing the target architecture, and coming up with a migration path that supported parallel operations of old and new world during the anticipated two years time the migration would take.

Of course in a decade the world has changed, so has the business and the way software has to be built to honor that. Globalization, European Union, changed customer’s perceptions, constantly changing demands, the way software is built, maintained, and operated.
So the job quickly grew to include a new domain model, adjusted business processes, better business alignment. So far the demands.

The agreed on strategy we came up with is an ecosystem of applications. One core application implements the main parts of a new domain data model, ensures consistency and — essential in any distributed system and surprisingly difficult to achieve at times — provides stable identifiers. Circled around this core application is a number of other mutually independent applications. (The possibility to do this of course relies on the business requirements being mutually independent.)

This approach is driven by

• the separation of the monolith in as many as possible disparate applications (pardon the exaggeration, but it is a fair number),
• defined ways of interaction between these applications (including off-the-shelf-software),
• and providing a sound basis to support building the custom-made family members.

This strategy provides the flexibility to build each application according to demand of specific stakeholders, even allowing for contradicting business demands of different departments. The set of applications can change in the future to address changed needs. Future technology changes can be applied in small steps (lessening the chance that will build the next Moloch). Maintenance should get better, because each application is less complex (simpler architecture, less business functions). And it conforms with Roger Sessions works on complexity of software systems.

Of course, a small but rigid set of rules and governance has to be implemented to ensure peaceful coexistence and avoid “chaotic growth” of our application family in the future. Especially the growth of interdependencies between the applications has to be watched carefully.

Next steps will be applying for the budget at the top management and then hopefully building that system. Of course with my and SDX participation 😉 .

Now, if that sounds like a challenging and interesting project; if you happen to be willing to work in the Rhein/Main area, Germany; if you could envision yourself working for the same company as I do 😉 … (not necessarily in that project!). Well then pay a look at http://www.sdx-ag.de/jobs.aspx (German language skills mandatory!).

That’s all for now folks,
AJ.SDX

Advertisement