jump to navigation

Notes on Enterprise Software Architecture – Part III October 12, 2007

Posted by Jeff in bpm, Business, collaboration, enterprise 2.0, Technology.

In our previous postings we looked at definitions, then at the structure of Enterprise Systems Architecture, and Enterprise Application Architecture.  In this posting, we go beyond the typical definitions, and look at some of the challenges that we have been addressing at Serus, and what their impact has been on our architecture.  We also discuss the definition and impact of Enterprise 2.0 technologies.

Serus is focused on the evolution of enterprise software architecture toward operations management.  This category of software deals with supporting the ongoing decision-making of schedulers, planners, manufacturing operations staff and managers, etc. 

Let’s take a minute to define the typical work environment of an operations manager:

It is the 10th week of the operational quarter.  The operations manager at NetworkDevices-Are-Us  doesn’t have a factory floor that he can visit to track the activities, since all of their chip production is carried out by TSMC or Amkor across the ocean.  After their chips are completed in Taiwan, they are tested and assembled at another facility, which is located in Japan.  Then the chips go into router manufacturing at Jabil in Florida, and then get shipped to a customer.  Each of these stages takes about 3 days of production time, plus about 3 days of transit time from one place to another.

The activities are scheduled according to a sales forecast for each week of the quarter, which was collaboratively created and reviewed back on week 5.  There was an update on forecasts, but that hasn’t been made into a new production plan.

This week, ND-A-U receives a new order for 5,000 routers from East Coast University, with a shipment date of the 13th week of the quarter (the corporate calendar organizes the weeks in 4 equal 13-week chunks).

To meet the order, he must reschedule several activities.  While trying to generate a few revised plans and alternatives, he gets a phone call that reports that there is a hurricane approaching Florida, and Jabil’s operations will be out for at least 4 days.

He then needs to carry out several scenarios, each of which represent different assumptions and approaches.

  • Redirect the standard production from Florida to another location
  • Also add in an extra amount for the ECU order, on the premise that it is a “blue-bird” order
  • Assume that ECU order is actually part of next week’s forecast, and simply shift those units one week earlier in time.
  • Create a baseline that shows the impact of the hurricane if nothing else is done, to get cost basis for amount of extra effort that must be accounted for in expedited shipments.

Once these plans are made, the best 2 or 3 will then be sent to the VP of Operations, for final review. It would be preferable for the system to maintain links between the resulting plans and the scenarios that created them, and the relative marketing forecasts and the new order, but actually all of these are in different emails or spreadsheets, so the operations manager has to attach all of them together into an email for the VP of operations, and then write a email that explains which attachment is part of what option.

All of these efforts by the operations manager work on live documents that are quantitative plans based on the forecast numbers, the production numbers, and use the corporate calendar.

Nature of the Required Changes in Enterprise Application Architecture

The standard enterprise application is not meeting needs because it is too:

  • Disconnected
  • Request-driven
  • Non-proactive
  • Keeps users in silos
  • Requires external recordkeeping, such as in spreadsheets
  • Provides little analytic support
  • Forces the user to look for the information

Enterprise Application Architecture in the 2.0 Era

In this design, the software layers start out in a similar vein as the previous discussion, which is to have a content management layer at the bottom. We have described the content mangement layer in more detail in our posting on Information Architecture for Design Support, as well as some of the background thoughts in our posting on Enterprise 2.0.

Conceptual Enterprise 2.0 Architecture Layers

However, at the middle layer, in addition to having boxes for business logic and similar components, there are engines for business processes, and for collaboration.   Some of the important boxes involve enterprise search, and collaboration.  The collaboration occurs on a number of levels.  Another important box is a classification and relationship engine.  This performs functions such as “what information is similar to this information”, or “what tags or classifications can be applied to this piece of information?”

Finally, there is a box for Context Management.  The simplest example would be a Notepad, however, our concept goes further to have a workflow case metaphor.  All information that is being worked with is done as part of some analysis, with a goal or intent.

Note that we deliberately avoided using terms such as “mashup”, “wiki”, or “blog”.  The reason is that we feel that terms that are examples of using the boxes shown in light blue, and in fact these terms may fade out.  Serus went through a similar line of reasoning in 2002, when we decided to avoid using terms like “e-whatever” or “i-whatever” which were currently in vogue to describe Internet-based products.  Our belief was that “internet” was a technology not a differentiator.

There are three areas: content, knowledge, and processes that must be addressed.

Management of Content

Since the Serus application is best viewed as a layer above one or more ERP or other operational system, its main purpose is to coordinate content in those systems, by providing a composite view.  This composite view is dynamically formed by joining content fetched from the external systems.

In many cases, the composite view is built “on the fly”, by fetching data from the external systems using protocols within the Enterprise Bridge, rather than storing it in the Serus application’s database.  In other cases, the information is cached or “snapshotted” within the Serus application’s database. While this is discussed in more detail below, an example is to store a combined demand forecast from a number of sources, including different geographic regions, allowing users to review and edit their portions of the combined plan, while having only view access to the other portions. 

In all cases, the Serus database and the content management layers also hold meta-data information about the content, such as catalogs and descriptions of content sources.  Another aspect is that the Serus application maintains change logs and audit trails, which again can span multiple content sources.  Finally, the Serus database provides configuration, administration, and personalization content.

In additional to the standard meta-data, the Content Management portions of the platform also allow for the definition of formulas that can be used to derive new content, using an expression and rule language.  These formulas include definition of key metrics and Key Performance Indictors, often shown on the Dashboard.

Another unique aspect of the Serus Content Manager is the definition of provisional overrides or changes to values, which can be organized into “scenarios” and “what-ifs”.

An example would be to create a scenario, in which the lead time for a key part is increased or decreased, and then generate and store the original and modified shipment plan.

Also in the Serus database and administration tools are facilities to define the business problem, such as defining the types of Organizations present in the system (Suppliers, Customers, Vendors, Warehouses, etc.), and the supply chain relationship between them (such as “which warehouses store goods from which suppliers?”, and “how are the categories of customers organized?”).  Some of the most important parts of the supply relationship information include sourcing rules, lead time values, cost values, and supply constraints.

Management of Knowledge

An Operations Management solution also provides access to the knowledge content of the ecosystem.  In that regard it acts like a portal to shared domain knowledge, such as best practices and approaches.  A good way to visualize this is to consider commonly used content portals, such as MyYahoo and Global Spec

The latter is an example of collaborative technical content.  There is only a limited amount of scrolling news.  Instead, there are links for questions and answers, browsing for products and suppliers, product announcements, and a set of tools.

Management of Scenarios

Decision support is more than just reporting.  It refers to the ability to perform what-if analysis within the application without affecting the other parts of the application and without saving the results to be transacted into other parts of the application until the user has arrived at a solution or result they like.  This involves changing numbers, rules, and parameters, then running an analysis, and then saving a scenario for future reference, and then running a new scenario.  A user may save three or more scenarios, then review with a group of people, once a final scenario has been selected, that scenario is then used to update or recalculate results or used to perform analyses in other modules.

Scenarios may be called up using a scenario access screen for a module, which aids by sorting the scenarios according to user-selectable criteria such as lowest cost:

Scenario Management Example


The recent round of corporate acquisitions in the reporting tools and middleware spaces (SAP, Business Objects, Oracle, and BEA) seems to confirm that idea that that the application building stack is being commoditized.


I read an interesting post that Knowledge Management is still a major pain point, despite numerous rounds of effort on it.  It points out that: “Much of the ‘KM is defunct’ hype in fact gets fueled by Google being so good at assisting the average user in getting to information quickly. But in the enterprise business environment, managing knowledge and information is a very real problem.”



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: