Finally, a way to describe IT!
Remarkably, there is no standard for describing what software, hardware and business applications you have, how it is deployed, what the dependencies are, how to tell whether something is working or not, or even how important it is.
We are going to change this. We are going to allow you to describe those parts of IT that your business depends on in a way that is understandable, maintainable and usable by your management systems. The work is almost complete, and the possibilities this opens up are very exciting.
Pattern spotting
Think of everything that we would like to describe as a variety of patterns
that may occur in the IT infrastructure. The trick is to allow all of the relevant patterns to be described in a way that makes sense to both humans and to software (so definitely no XML!) and to produce a lot of patterns to describe the stuff everybody uses as a starting point.
This is now possible, thanks to the Tideway Pattern Language. Internally, we affectionately refer to it as Tipple, although it seems likely that Marketing will change its name to something less interesting but more politically correct before it is released.
Tipple is a new, specialized language that is designed specifically for IT people to describe IT: the first of its kind.
Tipple is a common way of describing IT.
In the next version of Tideway Foundation, the core engine has been Tipple-enabled. In practical terms, this means that it is able to manage a large library of patterns and to “run” them whenever it discovers that a pattern may apply somewhere. In most cases, patterns are “triggered” on events that is caused by a Discovery sweep of the infrastructure.
To make it all much less abstract, let me share a few examples of what this means…
Anything is possible
A simple Tipple pattern used to describe Oracle servers could use the presence of a specific Oracle-related process as its trigger. When triggered, the pattern would then describe where to retrieve the version, patch levels, listening ports and other data about the Oracle server. In addition, the pattern could contain interesting information about the database server itself, such as its support owner, its publisher, and any other information that could be useful.
Tipple can also be used to express more than simple identification patterns like the one above; a unique and important aspect is the ability to express the lifecycle of identified patterns.
For example, imagine an important piece of software that is run intermittently as a batch process. Describing this in Tipple, we can specify the criteria for identifying it when it runs, but can also describe the criteria used to decide that it is no longer present in a standard form. The naive approach would assume that if it is not running, it no longer is present (kind of the reverse of the “is present” criteria), but this is clearly wrong in the case of a batch process. In this case, the criteria could instead be that the software’s log file has not been written to for a while, or that the executable file itself is gone, or something else.
More complex patterns described in Tipple can involve any number of steps to process or look up data, ask for more live information from the network (for example to retrieve a file and look up a key value) and to chain multiple steps together. Tipple also allows loops and conditions to drive more complicated logic.
Tipple uses these capabilities to make it easy to describe virtualized environments, such as VMWare or Solaris Zones, and other configurations such as clusters. All of this is intended to make sure that the model constructed and maintained by the Tipple-enabled system reflects reality: Tipple describes the IT in general terms as patterns, and the engine identifies where the patterns apply.
Clearly, these examples just scratch the surface of what it’s possible to do with Tipple and the new version of Foundation… It can be used to identify how a business application is composed and what it means for the business application to be unavailable. It can be used to easily spot deviations between a production and DR environment. It can be used to spot areas where your redundancy policies are violated. It can be used to spot critical changes. And much more; your imagination is the limit.
It’s all Tipple
All of this can be expressed in a simple, specialized language designed for just this purpose: Tipple.
Of course, Foundation will ship with a large number of pre-defined patterns for describing a lot of patterns that commonly occur: Virtualized environments, common IT infrastructure, common software, etc - and we ship updates to the pattern library all the time.
This means that the patterns are not embedded within inaccessible application source code but are freely available to review and even augment if necessary, they afford an unparalleled degree of freedom, flexibility and openness - something the security and risk assessment people will sure appreciate. The patterns also are not in XML: XML is fine for when computers need to exchange information, but quickly becomes impossible for humans to understand or write, whatever the marketing hype may say.
To ensure that Tipple can describe the patterns you care about, it is both extensible and flexible. It allows you to describe types of entities that we have not thought of, and allows you to add any number of attributes to the ones we have included out of the box, such as Software Instance or Business Application Instance. And new attributes are not treated like second class citizens either, but are fully integrated in the database, are indexed, searchable, and can be displayed in the User Interface.
Tipple makes it possible to describe IT in a sensible way.
It ships with the new Foundation release due out in October.
And there is so much more to that release; I’ll post more soon. Stay tuned.
PS : If you have a or question that you would rather not post here, feel free to send me an email - I am “a dot mertner at tideway.com”.
RSS