Log In
E-mail or User ID
  Keep me signed in
Recover Password
Create an Account

Ab Initio - On a Leash?


In that tome I coined and described the phrase "metamorphic super-pattern", then later trademarked the phrase and sold it to, you guessed it, Metamorphic Software Corporation in Dallas, Texas.

To clarify, the concept of "metamorphic software" is a software system that is malleable enough such that it feeds on metadata and predefined software objects to self-instantiate the application at run-time. In short, the "application" doesn't really exist as a compiled assembly with predefined behavior. It exists as a pattern of activity described by the metadata. Thus an application developer works with metadata patterns, not really with compiled software.

If you think this sounds like Java, you're wrong. Java represents the physical software logic, where metadata represents a business application pattern. Java represents the capability, where the metadata leverages capabilities to describe functionalities.

The application self-realizes at run time, combining predefined components with dynamic metadata to weave the application into existence. Once the application ceases running, it evaporates and the predefined components dissipate into the virtual ether. The metadata dynamically fuels the construction and behavior of the components and their interactions.

Is Ab Initio a "metamorphic" model? Some aspects of it are. The Co>Operating system certainly is, and the metadata script it feeds on represents the malleable, dynamic fuel. But this fuel is created by the Graphical Development Environment, which provides a visual picture of what is ultimately reduced to this metadata script.

Could you create the script without the GDE? Sure, but it's not very friendly. The GDE itself is not metamorphic, and neither is any other of AI's products. Only the Co>Operating system could be classified in this manner, but because it requires the GDE to harness the complexity of its operations, it is not the ideal metamorphic model. Pop open the GDE's generated script and the complexity will make your jaw drop.

A true metamorphic model completely reduces such complexity to a highly simplified and automated form. The metadata is thereby intuitive, not a "pile of Korn shell". Additionally, the Ab Initio model is lashed to a flow-based approach, so cannot be completely metamorphic in that transactional behavior is not a part of the substrate (It can be simulated, but only as some variation of the flow model) Note, however that a model that directly supports transactional operations is not as efficient in flow-based operations as Ab Initio, so there's a tradeoff.

Oracle and SQLServer are examples of metamorphic models in the data storage and processing domain. Tables, scripts, stored procedures and the like can be installed and operated all as customized structures and behaviors. The DBMS has predefined frameworks for handling the custom structures and behaviors, but nobody would disagree that such engines are finite - they address one domain of application problems.

Database engines have functional and capacity limitations that Ab Initio does not. Using their script-based programmable objects produces a more complex and disconnected result than the Ab Initio GDE. Ideally we should use AI to harness our business logic and the databases only to "store and retrieve". With all apologies to Oracle and SQLServer developers - the database is not the place to process data. It will inevitably run out of gas - and most of you have experienced this firsthand.

So with all this malleability, flexibility and diversity in our data processing realm(s), is it any wonder that so much confusion exists as to the direction to take toward a successful rollout of business functionality?

It's not enough to say that we "can" make it all happen, it's how we "should" make it all happen.

AI needs a framework to support it in the way of a development method, configuration method and the like. But what it really needs is a few seriously stoked developers who want to stretch its limits - all within limits.

Even though we put the technology on a leash, it's only to harness the technology's power for our own use. The next leash we'll need is for our own creativity - to keep things moving in a productive direction. Our IT leaders and their business customers aren't paying us for playtime - their problems are serious and failing to meet their goals can cause sometimes catastrophic results for careers, lives and businesses. Making it happen for them is sometimes inglorious and thankless for the implementers.

For certain, though, if we do it wrong we'll be back at our desks to fix it. If we do it right we'll be back at our desks preparing to deliver more. It serves our best interests in the long run to build parts we can leverage over again to accelerate us forward rather than requiring us to go back to the whiteboard.

So the leash is a good thing - a productive thing. Straining against the leash isn't all bad, but being unleashed is counterproductive.

So when I once spoke of things being on a leash - it was a tongue-in-cheek answer to all the books in print with titles such as "XYZ Unleashed" or promises to "Unleash the power of (fill in the blank)". No doubt, we want to unlock the power of these heavy-lifting power tools. But unlocking power and unleashing power are two different things. A nuclear reactor unlocks the power of the atom, where a thermonuclear device unleashes it. We see the same effect in our IT environments - an unleashed project is an unaccountable project.

Which brings us back to dough.

And lots of it - that is - to discover that our gaggle of developers have been building the next-generation-something-or-other on the ultimate-infinity-drive platform and will have wowie-zowie special effects complete with perpetual motion, time travel and reanimation of the dead. At least, these were on the wish list.

Somehow the swimlanes got tangled, the priorities got lost, there was a changing of the guard as half the contractors had to be hot-swapped because of expiring Visas, we lost the knowledge transfer, the original vision and the goals remain unharnessed. But now the problem is worse - because the train has left the station and we're not altogether sure what track it's on, what speed it's running, if all the passengers and cargo are aboard, and if it will ever arrive to its destination - not that we know what its actual destination is, you see, only that we hope it will arrive, save the day and make all our children smarter and more beautiful.


We need a leash - because this whole unleashed thing is not only tiresome, it's a roller-coaster ride for ourselves and our superiors - who look at our execution as more of a poor-man's three ring circus than a well-oiled machine. Our leaders will not suffer the roller coaster for long - they will either shut down the power or turn green and throw up over all our hard-won efforts and outcomes. And then what? The end is the same.

My children love to race pine cars - the 7-inch carved wood derby cars that race down a track powered only by imagination and gravity. Oh, the dreams of being first place, of smoking the competition - or rather - of spanking the competition. Oh - but in good sportsmanship, of course. A universal rule of the pine car derby is simply this: all of the cars start at the top of the track with the same potential - the only difference between the winners and the losers is friction. The more friction, the slower the car - because friction steals energy. Note we cannot say that the track itself is a source of friction - because it's the same for all. The true fulcrum of friction is elsewhere - and it will steal the project's energy if left unchecked.

Now look around you - is your leash actually a source of friction, or is it the delivery track itself? Do you have well-oiled change-management processes and utilities, or is the process itself slowing you to a crawl? Are your development procedures giving you lift and acceleration with each "agile" iteration, or are they just bogging you down? When you promote into production, are you holding your breath hoping it will work, or is the promotion simply the final step in a rock-solid and malleable assurance model? Is your administrative and operational model keystroke-intensive, or is it largely lights-out except for - well - exceptions?

I'm not talking blue-sky here - I'm talking about having some boiled-in reliable processes, some burned-in utilities to support them, and a reliable view of the environment from various aspects of administration, operation, maintenance, troubleshooting, etc.?

Is it easy to do? Of course not? Is there a path? Of course there is - it's using metadata as a means to define structure, behavior, configuration, outcome and logistical control. This means that the luxury to hard-wire anything is simply non-existent. The fallacy of tightly coupling disparate systems together is harnessed for what it is, and cremated on the premises. Metadata decouples structures while calling out that the coupling exists. It isolates behaviors while identifying that dependencies are known. It reports errors and logs to commonly accessible forums with actionable information - and it doesn't obfuscate or confuse the efforts of those who are responsible for keeping the systems from melting through the floor.

Does metadata make the world go round? Of course it does - and the fact that you can't see it spinning the planet is all the more a testimony to its effectiveness. Just as metadata in metamorphic environments is practically transparent, so metadata in data warehouse environments serves as an adaptive semantic layer - interfacing the user to the ultimate harness over the information.

In this regard - metadata is no longer data about data - it's the harness for the data - because it not only describes what data is, but how it came to be. What algorithms brought it forth - whether the algorithms succeeded or failed in their efforts to bring it forth - and the ability to change and accelerate the rate of those processes, the scalability of those processes and ultimately the accuracy and stability of those processes.

Which brings us back to scalability. Scalability is a function of both stability and adaptability. Without a stable system we cannot adapt. Without an adaptable system we cannot scale. So scalability is a moot argument if our work products are neither stable nor adaptable.

How is stability and adaptability accomplished?


Comment on this article

Leave a Comment

Connect to this blog to be notified of new entries.
You are not logged in.
Sign In to post unmoderated comments.
Join the community to create your free profile today.
Keyword Tags:  metadata abinitio ab initio on a leash metamorphic superpattern super-pattern

Receive the latest blog posts:
Share Your Perspective

PCMag Digital Group AdChoices

TRUSTe Privacy Certification