One EM to rule them all

So I thought I’d start with something lightweight to dip my toe in the water 😜. This one comes up all the time with customers large and small.

How many Enterprise Manager installations should I have ?

If customers are new to Enterprise Manager their default deployment architecture is often skewed by how they’ve deployed other “enterprise” applications & tooling or how they are structured as an organisation.

Design as a mirror of infrastructure design

Some installations simply follow their default infrastructure pattern design. If an organistion has embedded behaviour to build “Test”, “Production”, “QA” environments they will often (quite naturally) install their Enterprise Manager installations using a similar strategy. They will build-out an Enterprise Manager installation to manage their Production environment, then an Enterprise Manager installation to manage their Development environment. Sometimes they’ll also roll management of Test and QA into this “Dev” Enterprise Management build.

Design as a mirror of organisational or team structure

This deployment method is almost the same but the motivation behind this method is that deployments mirror operational team structures. The Production administrators use the Production EM, the Development administrators use the Development EM, etc. This type of deployment model fits neatly into organisations that are divided into “brigades” of management. As there are already organisational borders in place it naturally follows that other abstract borders are constructured around them.

They’re both similarly flawed…

Both designs have very similar disadvantages. They both lead to fragmentation of information about the enterprise. At some point as you navigate up the org chart you’ll come to a point where one person controls the purse strings that’s paying for all the infrastructure running a business (could be the CIO, CEO, CFO, whatever). With both of these implementation models this user will invoke a substantial work programme whenever she (or he) asks simple enterprise-wide questions. Any question that needs to be answered across the enterprise will, by necessity, spawn multiple tasks, often performed by different people, in different teams to independently go away and collect the information (in potentially independent formats), bring it back to the user requesting it, dump it on her/his desk and leave them to reformat and consolidate it themselves.

Looking on the operations side of the house, one of the most effective ways of driving down cost and complexity is conformity and uniformity. Standardisation is a really effective method for reducing speed of implementation and reducing cost of operations. Enterprise Manager can be a powerful tool to drive the consistency and uniformity across the enterprise. If everything is managed from one central Enterprise Manager configuration then this is achievable. If it’s a task that’s separated across multiple Enterprise Manager environments however that can reduce the effectiveness in achieve these goals. The tasks of managing consistency of deployments, configurations and monitoring/management standards across multiple EM environments is a process that at best has some basic levels of automation and at worst has a large amount of manual labour, human intensive tasks. Enterprise Manager was designed to be the central source of management for Oracle environments. The current EM data model does not natively lend itself to being a player in an federation of EM installations.

There’s a wealth of technical reasons that I could go on with here further supporting the flaws in having more than one EM environment but it’s worth touching on what it often, in my experience, one of the most difficult ones to avoid.

It’s the cost.

If you’re going to build out some Enterprise Manager infrastructure that is scalable, reliable and survivable (more on this in a future post) it’s going to cost some $’s/£’s/€’s* (delete as applicable). It’s a no-brainer to realise that if you have to do this more than once inside an enterprise it’s going to cost more than it would if you simply have one. Do 2 EM environments twice the cost of one ? Sometimes but not always, sometimes you can make it slightly cheaper to construct them if you’re partitioning the management of targets (the environments could be smaller, requiring less hardware). Sometimes it’s more expensive, particularly in the “team structure” model I point out above. There’s no sharing of operational burden between teams – they’ve got different budgets, different leaders, etc. No sharing increases the need for every team to have their own administration staff dedicated to that EM environment.

It’s important to ensure that if you rely on Enterprise Manager you ensure it’s built as a resilient architecture. Resilient architectures cost more than non-resilient, sometimes much more depending on the level of resilience required but one thing is certain – if you’re finding it hard to get the justification for funding to build one resilient Enterprise Manager deployment – you’re certainly not going to find it any easier getting the funding for 2 or 3 Enterprise Manager installations.

There’s always going to be some exceptions

Some people will point out that there are certain legal requirements for some organisations to have separate management infrastructure based on legal or territorial juristictions and I accept that in some cases these rules will be insurmountable. In these circumstances the Enterprise Manager administrator is forced to deal with the reality of trying to minimise the overhead of 2 or 3 of everything. There’s no getting away from it that sometimes this will be necessary.

What I do hope to convey here is that with a few exceptions I think the best value can be derived from a single Enterprise Manager installation. The benefits it can bring to an enterprise can be significantly greater and with lower cost than running two or three Enterprise Manager installations.

As a design rule I tend to follow the design method that I’ll start with one global enterprise manager deployment. Then I’ll let people tell me why I need to have more than one and if, and only if, there are solid reasons for having more than one I’ll try to design something to minimise the operational overhead of having two or more.

Next time …. why you need two EM’s 😜