Sharing the Solution Domain Taxonomy

Sometimes, Enterprise Architecture efforts fail.  This is no surprise to folks in the EA business.  This failure occurred slowly, back in 2007 and 2008.  But it did occur.  It took me a while to realize it.  I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution…

Agile and Wilful Blindness

@ruthmalan challenges @swardley on #Agile

Asked what is agile? It’s a method of reducing the cost of change when developing an uncertain act.
— swardley (@swardley) April 21, 2015

@swardley have you seen John Seddon’s quip: “Waterfall: doing the wrong thing righter. Agile: doing the wrong thing faster.”?
— ruth malan (@ruthmalan) April 21, 2015

@swardley in theory 🙂 What we’re paying attention to shapes what we perceive and pay attention to. etc.
— ruth malan (@ruthmalan) April 21, 2015

@swardley I was making a sophisticated/nuanced point. We canalize — we think we’re open to finding misdirection but it’s hard
— ruth malan (@ruthmalan) April 21, 2015


Some things are easier to change than others. The architect Frank Duffy proposed a theory of Shearing Layers, which was further developed and popularized by Stuart Brand. In this theory, the site and structure of a building are the most difficult to change, while skin and services are easier.

Let’s suppose Agile developers know how to optimize some of the aspects of a system, perhaps including skin and services. So it doesn’t matter if they get the skin and services wrong, because these can be changed later. This is the basic for @swardley’s point that you don’t need to know beforehand exactly what you are building.

But if they get the fundamentals wrong, such as site and structure, these are more difficult to change later. This is the basis for John Seddon’s point that Agile may simply build the wrong things faster.

And this is where @ruthmalan takes the argument to the next level. Because Agile developers are paying attention to the things they know how to change (skin, services), they may fail to pay attention to the things they don’t know how to change (site, structure). So they can throw themselves into refining and improving a system until it looks satisfactory (in their eyes), without ever seeing that it’s the wrong system in the wrong place.

One important function of architecture is to pay attention to the things that other people (such as developers) may miss – perhaps as a result of different scope or perspective or time horizon. In particular, architecture needs to pay attention to the things that are going to be most difficult or expensive to change, or that may affect the lifetime cost of some system. In other words, strategic risk. See my earlier post A Cautionary Tale (October 2012).


Wikipedia: Shearing Layers

Arguing with Drucker

@sheldrake via @cybersal challenges Peter Drucker on the purpose of business.”Peter Drucker asserted that the purpose of business is to create and keep a customer. He was right at the time in offering previously inward-looking firms a more appropriat…

Join Intact at HP Discover 2015

On June 2-4, Intact Technology will be attending HP Discover 2015 at The Venetian / The Palazzo Resort in Las Vegas, Nevada.
Thousands of IT professionals are expected to attend, in the hopes of seeing HP’s newest products and solutions. Featured at …

Microservices and the role of the digital business architect

Over the last 2-3 years organisations have gone through significant change. Existing capabilities have been transformed, and vast amount of new capabilities have been invested in to ensure organisations remain sticky in the customer’s digital life. Everything from collaboration, to new ways of working has enabled organisations to build deeper meaningful connections with their customers.  Read More

Zachman Enterprise Engineering – Primitive vs. Composite Review

Primitives and Composites – What’s the Difference?

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

Primitives are single-variable, ontologically-defined categories of the essential components upon which the Enterprise is dependent for existence. Only one type of Enterprise component can be classified in any one cell of the Zachman Framework. They are the domain of Engineering, that is, Architecture. They don’t “do” anything. In contrast, Composites are multi-variable, holistic constructs of parts or pieces of the Enterprise with components from multiple categories of the essential components. Representation of different categories of components (different Framework Cells) are prerequisite for implementation. They are the domain of Manufacturing. They implement (“run”).

There is a strong metaphorical correlation between the Elements and Compounds of the Chemistry discipline and the Primitives and Composites of the Enterprise Architecture domain. Elements (Primitives) are timeless. Compounds (Composites) are temporal. Elements (Primitives) have single types of components. Compounds (Composites) have multiple types of components. Elements (Primitives) are isolated theoretically for engineering work. Compounds (Composites) are integrated practically for manufacturing work. Elements (Primitives) are Architecture. Compounds (Composites) are implementations. Elements (Primitives) are needed for Engineering. Compounds (Composites) are used by and the result of Manufacturing. Compounds (Composites) can be manufactured without knowing anything about or reusing the Elements (Primitives), but for Compounds to be engineered to produce predictable and/or modifiable behavior, they must be created from “reusable” Elements (Primitives).

This brings up a very important point. If you had inventories of all of the Chemical Elements in their primitive states, you could manufacture ANY Chemical Compound you wanted. However, as soon as you create the compound, it is fixed … it is hard to change. By the same token, if you had all of the Enterprise Primitives in inventory in their pure Primitive state, you could create any Enterprise Composite implementation required. Once you create the Composite, it is fixed, a snapshot, a point in time instantiation… an implementation.

There is a metaphorical departure in Enterprise Architecture from Chemistry in the fact that the media of the Enterprise implementation is the same as the media of its descriptive representations, namely digital depictions. We do not have to go through a media transformation from our engineering descriptions to become our implemented reality. They can both be digital. We simply “compile” the implementation. However, we learned long ago that the moment you “bind” together the components of the Composite implementation, it is fixed … you can’t change it. Therefore, the optimum implementation strategy would be to “bind at execute time” … that is, don’t “compile” the implementation until you “click your mouse” … “late binding.”

Unfortunately, “bind at execute time” is not presently perceived to be technically feasible. I think most people would argue that it is because the current technology does not support the concept. I would suggest that this is not a technical issue at all. The fundamental problem is, we do not have an inventory of our Primitive (elemental) components in their pure Primitive state from which we could bind Composites together at the click of the mouse. The key to this capability is Enterprise Architecture, the inventory of Primitive components, “loosely coupled,” related only by “foreign keys” in a database (Repository). If we had the inventory of Primitive Models in a Repository, the current technology would, in fact, support the concept. This capability in Manufacturing, Industrial Age products, is called “Mass-Customization:” “Custom Products, Mass-Produced, in Quantities of One, for Immediate Delivery.” This is REALLY important for Enterprises in the Information Age … because of the dramatic escalation of complexity and of the rate of change, the ENTERPRISE needs to be mass- produced from reusable components already “in inventory” in quantities of one for immediate instantiation … dynamically creating (late-binding) a new Enterprise implementation. This is the urgent motivation for ENTERPRISE ARCHITECTURE!!!

Is Database-as-a-Service in your IT Services Catalog?

Are You Ahead or Behind theCurve?

Private Database Cloud Services or Database as a Service(DBaaS) is no longer a new idea. Infact, it is quickly becoming the de facto standard for development and testingenvironments both on premises and in the public cloud. And while there are many use cases anddeployment options, overall database total cost of ownership and businessagility have benefited from a standardized approach to workloadmanagement. Whether you are a DBA, anoperations manager, or a CIO, you are well aware that business-driven interestin social, mobile, big data, and internet of things have caused an explosion ofdevelopment, data, and database workloads. The justification for database operations to pool resources andstandardize services has never been clearer – watch thiscustomer story (TRT1:30).

Today’s best practices in cloud architecture expect serverscalability, zero data loss resiliency, and most importantly workload securityand isolation through multitenancy. For database services, the architecturewould be incomplete if database operations did not also natively supportmultitenancy. Initial approaches for DBaaSwere limited since they only relied upon virtual machines for workloadisolation and database provisioning. As general technology containers, VMs hadno intrinsic understanding of database operations, so they were unable to optimizeperformance, scalability, and resilience as well as simplify databaseadministration efforts.

Today’s best practice for database cloud services overcomesthese limitations. The Oracle PrivateDatabase Cloud approach is both revolutionary and elegantly simple. By engineering multitenant capabilities throughoutthe Oracle database platform, the complete range of database operations andadministration can now be natively managed andwithout the overhead of a virtual machine. Oracle’s Private Database Cloud guarantees isolation and leveragesOracle’s strengths in reliability, scalability, security, and systemsmanagement. Large database estates also benefit from a host of relatedcapabilities, such as cost-recovery reporting, self-service management, andpublic cloud integration. You will findthat Oracle database platform is ideal for a standardized enterprise deploymentor cloud service, whether development/test or production – watch thiscustomer story (TRT2:17).

Oracle offers a reference architecture overview and Oracleproduct mapping for DBaaS in a private cloud deployment model. The approach and guidance offered is thebyproduct of hundreds of customer projects and highlights the decisions thatcustomers faced in the course of their architecture planning andimplementations. Oracle’s advisingarchitects work across many industries and government agencies and havedeveloped standardized methodology based on enterprise architecture bestpractices. Oracle’s enterprise architecture approach and framework are articulatedin the Oracle Architecture Development Process (OADP) and the Oracle EnterpriseArchitecture Framework (OEAF).

Click here for an Enterprise Architecture approach to the Oracle Private Database Cloud

Table of contents:

Executive Summary 1

Fundamental Concepts 2

  • What is a Private Database Cloud andDatabase as a Service?
  • Why Consider Database as a Service?
  • What is Different about Database as aService?
  • Considering Moving to Database as aService?

Architectural Perspectives 5

  • Architecture Principles
  • DBaaS Architecture Domains

Architecture Views 8

  • Conceptual Architecture Overview
  • DBaaS Management Capabilities andProcess Overview
  • DBaaS Physical Architecture

Conclusion