This post is obsolete

This blog post is quite old, and a lot has changed since then. Meanwhile, I have changed employer, blogging platform, software stack, infrastructure, interests, and more.
You will probably find more recent and relevant information about the topics discussed here elsewhere.
Still, this content is provided here for historical reasons, but please don’t expect it to be current or authoritative at this point.
Thanks for stopping by!

The Rise of Engineered Systems

Mercedes car, broken down into components.

I changed into a new role at Oracle: I now work for the EMEA Engineered Systems Architecture Team (ESAT). We support Oracle’s EMEA Engineered Systems business by engaging with customers, enabling our field organization with trainings and through evangelization.

You can call me biased towards Engineered Systems (no link, page no longer exists) now, but that would be like accusing a Mac fanboy of suffering from the Stockholm Syndrome, when it’s actually the other way round.

The other side of the “biased” medal really is that I have a choice of where I want to work, and one of the reasons I changed from my cozy SPARC/Solaris Technology camp to the Engineered Systems crowd is: I believe the world of IT is changing.

Let me explain.

Back to the Future

Once upon a time, when computers were new, they came as a whole: You bought yourself a “computer” and it came with everything you needed to get started: Hardware to compute with, storage to store data with and software to work with. Those times culminated in the rise of mainframes that offered everything a business wanted to do with computers as one whole, integrated, single package.

Even through the 70s, when mainframes got replaced by minicomputers, they still came as an integrated whole: Storage, Computing hardware, OS and development tools with libraries, what we would today call “Middleware”. (For a fascinating travel in time back to the minicomputer era, read “The Soul of a New Machine”*).

But then the integrated approach was seen as too proprietary and too limiting, which gave rise to a new wave of systems in the 80s: Open Systems. Now, vendors offered the pieces (You know: Storage, Servers, OS, Tools and Middleware, Applications, Networking and so on), while businesses (or system integrators, for a fee) put the pieces together into a customized whole.

30 years later, we’re still living in the 80s, when it comes to running an IT project.

A Typical IT Project

So how does a typical IT project work?

  1. Someone has an idea for a new business capability. “We need an app store for our iToaster company!”

  2. Bright people create an IT architecture to support that new capability. “Here’s our blueprint for a private cloud based, full-featured, interactive, augmented reality, HTLM5, AJAX iToaster App Store system, complete with CRM integration, web portal, BI engine and ToastHabits™ loyalty card integration!”

  3. A round of RFPs goes out to procure the components for the new system: Storage, Servers, Networking, Virtualization, OS, Database, Middleware and some Applications. Some of these are standardized, but we still end up with more than a handful of them, multiplied by our company’s list of n>1 favorite vendors to play against each other.

  4. RFP responses are evaluated. Technologies are studied, claims verified, proof-of-concepts are run, pilots are conducted and so on. Lots of traveling, playing, arguing.

  5. Finally, the components of the IT system are decided on. The result tends to look like a camel (which allegedly is an animal that was created by a committee): The number of vendors involved is only slightly smaller than the number of components across the storage-to-application stack, thanks to elaborate purchasing rules, standardized buying practices, old relationships or just habits of the people involved in the process.

  6. Then the pieces come in and the IT department gets to play. Storage is set up and plugged to servers through some network, servers are set up and provisioned with virtualization and operating systems, databases are set up and connected to middleware which is being rolled out to support the actual applications that matter and so on.

  7. In the process of putting the components together, problems emerge. The storage doesn’t like to play well with the server, which turns out to be a firmware issue after weeks of finger-pointing between vendors and countless hours on their hotlines. The OS needs a specific patch and some settings in /etc/system to support the right version of the database so it can optimally talk to the middleware, but there’s still a network latency or routing issue which drags down performance because the NAS device tends to overload specific segments more than the middleware communication to the database so different networking paths need to be set up, and so on.

  8. Finally, after months of delay the new IT system is running. Kinda. A bright guy came up with a creative solution so the project doesn’t have to be delayed again. The “solution” also compromises security a little bit, but that’s a small price to pay for cutting weeks or months off time-to-market and reach the huge potential of hundreds of thousands of new customers (and their credit cards) and turn them into revenue through the magic of the new system. And we’ll fix the security bugs later. When we have the time.

  9. Only, it is not running very well, yet. Performance problems arise, once more than 10,000 customers try to place orders at the same time, which happens on the very first day because the new service was announced with a huge marketing campaign. On the management floors, biological end products hit rotational dynamics which only worsens the problem because now even more people try to use the new system just to see what the problem is. The press isn’t helping either. The test department guy says they shouldn’t have brought the system online without running any further tests while the business people point at charts with “opportunity costs” due to the already mind-blowing project delays.

  10. I’ll spare you the details of the first successful hacking attempt.

True, this is exaggerated for reasons of entertainment, but things like this happen all the time in current, “modern” IT shops. I’ve seen them all in two decades of working in IT and I’m sure you’ll recognize a few of them, too.

The point is: Building IT systems is complicated, time-consuming, error-prone, unpredictable, resource-intensive, expensive and risky.

Or, more shortly: The way we build IT today is broken.

The Return of the Engineered System

Wouldn’t it be nice if you could just buy a full system that comes with everything you need to get started on your new business idea? A system where storage, networking, servers, virtualization, operating system, database and middleware, applications are engineered together, tested together, certified together, delivered together, managed and patched together?

Unpack, set up and get started in days, not months. Roll out your application without the risk of it blowing up due to unforeseen incompatibilities. Profit from better performance because all components are pre-integrated, so they can use a faster networking technology than the generic standard. Less suffering from bugs because most of them have been fixed already at the factory level rather than at the customer site. Less support suffering because the guy at the other end of the phone has access to exactly the same system and can therefore understand your issue much better. Better security because everything has been designed together with security in mind and in a pre-packaged way with controlled interfaces in and out of the system as a whole. Shorter time-to-market because steps 3-10 of the above process are reduced into one step that only takes a few days: Unpack and configure your Engineered System.

That’s what Oracle’s Engineered Systems (no link, page no longer exists) are about.

It sounds similar to the early times of computing, where the 10-step process from above was just two:

  1. Buy computer.

  2. Get to work.

And that’s the goal of Engineered Systems: Get rid of the maddening complexity of building IT systems and let the people sort it out that do this actually for a living, 100% of the time and with much better expertise.

And the goal for you is to get to work on what you are best qualified for. Building App Stores. Selling stuff through e-commerce. Collecting big data and finding sense therein. Running social networks. Figuring out where the economy is going. Making sure that parcels go from A to B on time during the christmas season. And so on.

But isn’t this going back to monolithic, proprietary and closed systems?

Of course it is not. The thing is that we’re getting the best of both worlds: Simple IT deployment, and open standards with open interfaces across all components of the stack.

There is no lock-in: All software that comes with Engineered Systems is identical to the software that you can buy independently as a component of your 10-step home-brew IT deployment process. If you don’t like the Engineered System, just build your own IT and move your stuff onto it, while keeping the same OS, middleware or database software.

Yes, there’s the occasional tool that is specific to the Engineered System it ships with, but these are extra components for convenience, like the customized dashboard on your Volkswagen that doesn’t make sense if you duct-tape it onto your Toyota. Which brings us to:

Analogies Galore!

Engineered Systems are often compared to cars. And the analogy is striking: When was the last time you ran RFPs for tires, engines, transmission, seats, dashboards, chassis and bodywork?

Indeed, when cars were invented, each car was individually built to the driver’s specs. Until Henry Ford came along, and the rest is history:

Any customer can have an Engineered System painted any color that he wants as long as it is gray.

A friend of mine came up with a much better analogy: Beer! Ever tried brewing your own beer? Sure, a liter of home-brew is cheaper than a liter of your favorite beer brand, but good luck going through the elaborate process of setting up, cleaning, roasting, fermenting, brewing and bottling your own beer. One word: Hygiene.

The result can taste great, but often enough, something (usually bacteria related) goes wrong and you end up with a beverage that tastes, well, home-brewn. And then you’re sitting on 20 liters of something that your friends politely called “interesting” and that you’re too proud of to dump into the sewer for a few bottles of good, proper German beer.

Which is not far from “interesting” IT solutions we see a lot, their creators being too proud to replace them with something that actually works.

Engineered Systems are the Bavarian beers of IT.

You can find a great analogy much closer to traditional IT: Just walk into any coffee shop, better yet, visit any conference and look at the number of MacBooks vs. laptop PCs, iPhones, vs. Android phones, and of course iPads. Particularly their users and the amount of “work” vs. “fix” they do on their devices.

The iPad is the ultimate consumer Engineered System: Hardware and software and applications merged into a single, optimized system that lets you “just work”.

Change is Coming

Expect professional IT to change the way the car industry changed, or the way Apple changed the consumer industry: Companies are starting to build IT out of large, pre-engineered building blocks, vs. re-inventing wheels at the component level.

When was the last time you pondered whether to use Hitachi, Seagate or Conner drives for your storage project? Do you really care about the chip sitting inside your networking card or storage controller? Are you still busy testing, sourcing and integrating hardware and software components while your colleagues are treating the system as a component?

The focus of professional IT has now been elevated: From building systems out of components to building clouds out of pre-engineered systems. That’s where IT is going in 2012.

So What Do They Look Like?

Oh, I almost forgot. This is not a product pitch, so I’ll be brief:

  • Exadata (no link, page no longer exists) is the Engineered System for running Databases.

  • Exalogic (no link, page no longer exists) is the Engineered System for running Middleware and Applications, including SAP. (And one of my first duties as part of my group was to write a white paper about “Running SAP NetWeaver on the Oracle Exalogic Elastic Cloud (no link, page no longer exists)”)

  • The Oracle Database Appliance (no link, page no longer exists) is the easiest to use, all-in-one database appliance for small and medium enterprises or individual departments.

  • The Big Data Appliance (no link, page no longer exists) makes it easy to pre-process Big Data for your database, NoSQL included.

  • Exalytics (no link, page no longer exists) is the Business Intelligence System that leverages 1 TB of RAM to slice and dice huge amounts of data at lightning speed.

  • SPARC SuperCluster (no link, page no longer exists) is the most flexible Engineered System: It comes with both Exadata and Exalogic technologies to boost database and middleware performance within the same box, and it can run any other application, too. A full Enterprise IT stack in a single box. I can’t wait to see SAP certified on this baby!

  • The ZFS Storage Appliances (no link, page no longer exists) are part of Oracle’s Engineered Systems, too. The one-stop shop for a wide range of storage requirements. It’s also used within Exalogic and SPARC SuperCluster as a common repository for compute nodes.

Your Take on Engineered Systems

What do you think? Do you see how Engineered Systems change IT? Or do you still see value in building stuff from scratch, over and over again?

What are your experiences with Engineered Systems? What aspects of Engineered Systems would you like to see covered in this blog?

Drop me a few lines of comment below, or send me mail. Let’s discuss!

*: Amazon affiliate link. Buy cool books at no extra charge, and I’ll get a small kickback. We both win!

Car picture by Flickr user flamesworddragon, used under Creative Commons License.


Commenting is currently not available, because I’d like to avoid cookies on this site. I may or may not endeavor into building my own commenting system at some time, who knows?

Meanwhile, please use the Contact form to send me your comments.

Thank you!


This is the blog of Constantin Gonzalez, a Solutions Architect at Amazon Web Services, with more than 25 years of IT experience.

The views expressed in this blog are my own and do not necessarily reflect the views of my current or previous employers.

Copyright © 2022 – Constantin Gonzalez – Some rights reserved.
By using this site you agree to not hold the author responsible for anything related to this site. See Site Info/Imprint for details and our information policy.

This site was built using Pelican, which is written in Python, using a homegrown theme that borrows heavily from Elegant. It is hosted on Amazon S3 and distributed through Amazon CloudFront.