Engineered Systems and Enterprise Architecture (Or: How to Sell Dog Food Online)

One of the first things that customers and sales teams realize when dealing with Engineered Systems is: They fundamentally change the IT architecture of a business.

Change is good, it means progress. But change is sometimes seen as a bad thing: Change comes with fear.

The truth is that Engineered Systems really empower IT architects to add value to their business, application and data architectures, without worrying about the technology architecture.

To understand this, we need to dig a bit deeper into Enterprise Architecture, specifically the TOGAF flavor of it.

One of my first tasks as a member of my new team was to get TOGAF certified. TOGAF is “The Open Group Architecture Framework” which is a fancy name for a giant document full of definitions, models, and methods for creating IT architecture out of a given business capability need.

Let’s look at a simple example: Suppose you’re the owner of a big dog food business empire. Your core competency is to know all about creating the best dog food, knowing your customer’s dog feeding preferences and habits, and having the best suppliers of dog food ingredients lined up from partners to help you excel at selling dog food.

And now you want to take your business to the next level and start selling dog food online. Here’s the typical progression of steps, assuming your company has successfully introduced TOGAF as your method of doing Enterprise Architecture, according to the TOGAF Architecture Development Method (ADM):

TOGAF ADM for Dummies

1. Architecture Vision: Your boss told you to come up with an architecture for adding an online shop to your dog food business. The first step then is to create an architecture vision: How does it look like to sell dog food online? Who are the stakeholders for such a capability and what are their concerns?
2. Business Architecture: Your enterprise architects sit down through numerous meetings with your business people, identifying a business architecture for selling dog food online. This is a bunch of diagrams, catalogs and matrices describing exactly how your online shop capability ties into the rest of your dog food business: What’s your online dog food business model? What are the use cases you want to support through your new capability? What existing processes does the new capability tie into? What new processes need to be defined to add the online shop capability? The output of this stage uses business building blocks: Business processes and capabilities, modeled at a very high level, and technology-agnostic, specific to your enterprise.
3. Information Systems Architecture: Your enterprise architects translate the business architecture created in step 2 into an information system representation, which is composed of two architectures, a data architecture and an application architecture:
   1. The Data Architecture describes what kind of data you need to take care of for your online shop capability. Customer data, product data, payment data, shipping data, dog pictures, food pictures, dog food ingredient lists, all of it. It also describes where the data comes from, where it flows to, who needs what data when and so on. We see two types of data here: Structured data (what you’d place into a database) and unstructured data (i.e.: flat files).
   2. The Application Architecture describes what applications you need to handle your data: Web portals, CRM applications, supply chain management applications, shipping and tracking applications, order management applications, payment processing applications, dog food personalization and mixing order processing applications etc. More diagrams, more catalogs and more matrices are created to describe this stage of building your dog food online shopping empire. Notice that there are no particular technologies and no products considered at this stage either.
   The building blocks at this stage: Applications, database schemas, flat file specs. All particular to your enterprise.
4. Technology Architecture: The next step is to translate the information systems architecture into a technology architecture. Now we’re getting somewhere: This is where our enterprise architecture heroes get to describe what systems are needed where, how to map applications and data to those systems, what networks to use, which servers are connected how at what locations, etc. And here comes the cut: The building blocks are now generic! A database server is a database server, no matter what it stores, be it dog food recipes or car configurations. An app server is an app server, no matter what app runs on top of it, same goes for a file server, a firewall or a router. All components of Technology Architecture are generic, there’s hardly anything specific about selling dog food online here.
5. Opportunities and Solutions: This is the earliest stage at which particular technologies (such as the Oracle database) come into play and where specific instances of a technology (“Our main CRM system running on Oracle on SPARC SuperCluster.”) are mentioned.
6. Migration Planning: Here’s where the hand-over from the enterprise architects to the project managers occurs: Implementation and migration plans are forged, projects are created and prioritized, resources are allocated, hands become dirty.
7. Implementation Governance: This stage ensures synchronization between Enterprise Architecture and its implementation, as carried out by you project managers, through running reviews and monitoring progress.
8. Architecture Change Management: Finally the project is done, the dog food online shop goes live and hopefully the first orders come in. Parties are thrown and people get drunk. The next day, lessons are learned and captured, and fed into the next ADM cycle, starting again with an architecture vision. Perhaps the beta users identified a few bugs or RFEs, or the product managers have new ideas for what else the online dog food store could sell, but that would require a new capability to be added to the architecture: The cycle starts again.

The Limits of Creating Business Specific Value

What does this have to do with Oracle’s Engineered Systems? The answer is that it’s all about who creates unique value at what level of the architecture and who doesn’t:

• Steps A-C are highly specific to the enterprise: This is where enterprises truly innovate: The first online shop exclusively for dogs! Online dog food customization! Geo-aware local dog food sourcing! The value at these stages is unique to the particular enterprise, or at least the vertical business it operates in.

• But step D (Technology Architecture) is different: All building blocks here are generic, and there’s hardly any value for a typical enterprise to create here that differentiates themselves from other enterprises. How is a database cluster developed for a dog food database different in design than a database cluster developed for a car configuration database? Or why would a file server for hosting dog pictures be significantly different from a file server for hosting book covers?

• All other steps starting from 4 follow the same pattern: Building blocks, best practices and implementation details are the same, there’s nothing specific to the particular business that they support. They all need to be secure, performant, reliable and more or less highly available. All business use the same trucks to deliver their goods, only very specialized business may occasionally need a special truck, but they’re quite a minority.

And yet, businesses spend enormous amounts of resources for coming up with their own custom made database cluster design, their own custom made app server farm design, their own custom made file server infrastructure design, their own custom made web infrastructure design and so on.

This is where the rise of Engineered Systems takes place.

The Engineered System: TOGAF Stage D in a Box

Oracle’s Engineered Systems (you know, Exadata, Exalogic, SPARC SuperCluster, ZFS Storage Appliance and so on) are nothing more than the TOGAF stage D of the ADM in a few, easy to plan, buy, install, manage boxes, without the usual headaches that used to occur when planning Technology Architecture.

Want a new database for your dog food recipes? Just ask the DBA to allocate one for you out of an Exadata. Want to host the entire chain of app servers and portal that forms the application layer of your dog food shopping empire? Push a button on your PaaS portal to instantiate a virtual assembly on one of your Exalogic boxes. Want something more powerful? Perhaps with more transactional crypto-oomph? Ask you friendly PaaS portal for a slice off of your shiny new SPARC SuperCluster. Wanna analyze heaps of personalized dog food recipes and correlate them with mailman assault reports, dog flu epidemic data and weather forecasts? That’s what the big data appliance and Exalytics are for.

The point here is: No business should spend time, money and resources for creating yet another personalized flavor of a RAC cluster, an app server tier or a web portal infrastructure. This is what IT companies like Oracle can do better than anyone else: Design Technology Architecture.

Instead, use your energy and resources to create real business value. What’s your online dog food architecture?

P.S.: Please forgive my dog food analogy. Here’s the Guy who planted it into my mind:

TOGAF ADM picture taken from Wikipedia, used under NASA public domain policy. Dog picture by digital_image_fan on Flickr, used under Creative Commons license.