Consolidation as an industry trend - Expert Consolidation in Oracle Database 12c - page 15

a different set of hardware. In that case the systems are great candidates for consolidation, and we have come full
circle to the first sections in this chapter. Whichever way the future direction of the common IT department goes, any
change should be introduced gently so as not to alienate the “other” team!
However, an acquisition does not necessarily imply a negative challenge from a technical point of view.
Sometimes companies are too successful, however paradoxical that might sound. Business units in such companies
are very likely too busy adapting to the rapid requirements of customers to deliver new functionality in their software
products that there is simply no time to develop a standards framework. And quite often there is not even time to
consider how the estate should be managed when a “steady phase” is eventually reached. In such circumstances the
acquisition of another company that has reached a healthy balance between the requirement to produce new features
and the need to develop a corporate standard is most likely a great opportunity. Instead of having to reinvent the
wheel, an existing standard model can be used as a baseline and refined to match the growing company's needs.
How much standardization is needed?
Defining the scope of the standards set to be implemented is a difficult task. You read in the introduction to the
standards section that very few business units use engineered builds right from the outset of their existence. As a
direct result, very few Oracle installations look alike. And as you also read before, this makes it difficult for someone
who is not familiar with an environment to support it efficiently. But often, as soon as efforts are set underfoot to align
the configurations, difficulties are not far down the line.
The first logical choice is to set up a central body responsible for the definition of the standards. In large
companies, this usually ends up in the hands of the engineering department. After this transition of “power,” it is
possible that regional or product-aligned representatives, who in the past decided about deployments, versions, and
other details feel sidelined.
Again, a gentle approach by the engineering department is needed, and as you can imagine regional
representatives might need gentle nudging from time to time to move in unison. Where appropriate, regional “best
practices” should be considered for inclusion in the standards document, and certainly not brushed aside. In the
same way as concessions need to be considered, it also has to be made clear that the owner of the standards has the
final say in how a specific feature is to be implemented. Therefore it is very important that the engineering department
or whichever other team performs the task has full backing from management.
New environments brought into the organization, for example appliances which offer little (or less) possibility
to fine-tune the setup pose a challenge. Should the appliance be “pressed” to fit the corporate standards, or should
it remain outside? This question can only be answered individually. Very often, vendors claim their appliance is
specifically built to make it easier to support. This may be true for the vendor, but not necessarily for the customer. If
your vendor is flexible, it should hopefully be less of a problem to integrate standards into the product, but you might
have to take initial teething problems into account. On the upside, however, management of the environment can be
greatly simplified, and another application-specific siloed team of DBAs is avoided.
Another challenge is the evolution of standards. As business requirements change, and companies adopt new
technologies, existing standard documents have to be reviewed periodically to ensure the current standard document
is not holding the teams back. Such a review is more or less unavoidable when a new Oracle database release is
adopted for production use. In this case though there should not be any problem to incorporate a new feature into
the standard since it cannot collide with anything in the standards document. If the document structure permits
it you could simply add a section pertaining to the new release. The standards-owner needs to discuss whether or
not fundamental changes to the standard are retrofitted into existing environments or not. If it is decided to only
build new systems to the current specification, environments could become fragmented again. On the other hand,
changing environments to match the standards can be a very time-consuming process and most likely requires an
outage, especially of the operating system or Oracle directory structure is touched upon. It is to hope that the standard
document is suitably mature before modification to prevent said fragmentation and to preserve a common set of
commands and directory structures. A newly developed consolidation platform is a great opportunity to test and
implement the latest edition of the standards, and to ensure they are suitable for this kind of environment. Before
going into detail as to which elements of the software stack could be standardized, a little discussion of the different
aspects is necessary.