All posts by Ben Eng

I am a software architect in the Communications Global Business Unit (CGBU) within Oracle. I currently work on communications solutions that integrate a complete stack of Business Support System (BSS) and Operations Support System (OSS) applications. My previous responsibilities include product management of the Oracle Communications OSS Suite to provide an integrated suite of OSS applications for communications providers.
I founded the Oracle Communications Service & Subscriber Management (S&SM) application and the Oracle Communications Unified Inventory Management (UIM) application. I pioneered the adoption of Object Relational Mapping (ORM) based persistence techniques within OSS applications. I introduced the XML Schema based entity relationship modeling language, which is compiled into the persistent object modeling service. I established the notion of a valid time temporal object model and database schema for life cycle management of entities and the ability to travel through time by querying with a temporal frame of reference or a time window of interest. I established the patterns for resource consumption for capacity management. I championed the development of Web based user interfaces and Web Services for SOA based integration of OSS applications. I was responsible for single handedly developing the entire prototype that formed the foundation of the current generation of the OSS inventory application. I have been engaged in solution architecture with service providers to adopt and deploy Oracle's OSS applications across the globe. I am responsible for requirements analysis and architectural design for the Order-to-Activate Process Integration Pack (PIP) proposed to integrate the OSS application suite for the communications industry using the Application Integration Architecture (AIA).
Any opinions expressed on this site are my own, and do not necessarily reflect the views of Oracle.

Product management is notorious for being risk averse. This often comes from a history of dealing with frequent failures to deliver on time and with quality due to chronic cost-value entanglement. This initial architectural failure cripples a product forever, unless the root cause of the problem is recognized and corrected. Risk aversion grows as the product becomes brittle, and development becomes unwieldy due to ever-increasing code complexity.

Architecture is often thought of as a design function, but this is far from accurate. Use case and requirements analysis are specification activities, which are central to product architecture. It is most important to identify how its users interact with the system and what functions a system performs. These aspects of the system should be encapsulated by its facade, the boundary between the externally visible behavior (interfaces) and its internal implementation. Poor product specification and poor separation between interface and implementation are the architectural manifestations of cost-value entanglement.

This leads to product management demanding a meticulous “evolutionary” approach to development, meaning only small patchwork enhancements are permitted. Significant redesign and technological improvements are impossible, because internal changes will disrupt the externally visible behavior, breaking things for the installed base of users. Such unreasonable constraints can be alleviated by disentangling the facade from the internals. Clearly identify the externally visible concepts in a precise model to support human understanding and interfaces for programmatic access. This enables evolving the facade independently of radical redesigns to the internal implementation. Without this flexibility, revolutionary change is impossible, if quality and time to market are to be maintained.

I have noticed that there are those who blaze the trail, and lead the world kicking and screaming into the frontier. Then, there are those who are willing to follow, but have little to blaze for themselves. Finally, there are those who refuse to follow, but have no skills to lead either.

What do we do, when we want to learn something? Research what others have done before. The vast majority of things can be accomplished without a deep understanding of the problem or solution; it just requires emulating success. Someone else did the hard work of understanding, and documented a procedure and a simplified explanation that others could absorb and reproduce. That is how humans work. To become a successful trailblazer requires a deep understanding for oneself, but also the ability to distill that into simple explanations and instructions that ordinary people can absorb. The sophisticated knowledge will probably be taken to the grave, but it is the idiot’s guide that will endure the ages.

Ordinary men need traditions and procedures to emulate. Otherwise, they wouldn’t be able to even feed themselves. Imagine the vast knowledge and investment in thought that was required to invent the cooking recipes that we know today. Many people would starve today if they were responsible for acquiring that knowledge themselves through creative thinking, rather than by emulation. Traditions, rituals, and procedures bring comfort to us, because it relieves our burden to think. Most people are incapable of advanced contemplation; emulation is their only recourse. It also instills a common denominator in a society’s culture, and it binds them together psychologically.

We grow up emulating our parents and neighbors by decorating a tree, putting up lights, singing songs, exchanging gifts, and gathering with loved ones. There is comfort in these mindless activities, because they are familiar and safe. This manner of blind emulation leaves us vulnerable to less benign inclinations, like smoking or religion. Ritualistic activities give me no comfort at all. Tis the season to celebrate the most basic survival technique: mindless emulation.

With software, the value is in the concepts (model), brand (reputation), people (experience), and customers (installed base). Not so much the design or implementation artifacts. Often we place too much focus on the code, because it is the most tangible manifestation of our investment. This is a grave error. The code is the result of the sunk cost, but it is not the true value of a software product. The value lies in the capabilities enabled by the software. The software is the means, not the ends. The code must be free to evolve rapidly and radically. If it is not, it will not be able to survive in this ever-changing business environment.

Software organizations that are code-centric have long product release cycles, slow response times to changing requirements, and poor agility to scale the business to expand its market. Code-centric organizations rely heavily upon a skilled development team’s intimate and long-standing relationship to the code. This leaves them vulnerable to competition and employee turnover.

We must be value-centric, not cost-centric in identifying goals. The value is the ends, whereas the costs are the means. The costs (code) must be very flexible, adjusting with agility to the times. The value must be durable. The value must be identified, disentangled from the costs, represented tangibly and separately, and communicated widely. Cost reduction implies discounting investment in code. Decoupling value from code as much as possible allows costs to be reduced without impacting the value.

Complexity grows with code size. Costs grow nonlinearly with code complexity. When you suffer from cost-value entanglement, then code complexity will sink your entire product in time. Entanglement takes away the ability to significantly redesign and reorganize the code, because it puts the value at tremendous risk. Without the freedom to significantly redesign, eventually the product will collapse under the ever-growing weight of its code complexity.

Since the beginning of April, my primary mission has been to document the Reference Architecture specification, which will drive our business. One important lesson I learned in the past year, while observing the executives direct the organization, is to deliver simple messages. People need simple terms to remember complex chains of thought. That is why naming (branding) is so crucial to success. It is also a key to the success of any strategy.

The mission that I set myself to accomplish was to distill the myriad strategic messages handed down from executives into two simple messages. Then, to expand those messages into a technical architecture for executing on the strategy. As I was waiting for the bus today, I came to the realization that these two strategic messages are as applicable to ordinary life as they are to the success of our business. So I present them here.

Focus: Concentrate your investments on your core business. Understand your strengths and use them to your advantage; avoid over-extending yourself into endeavors that expose your weakness. Do what you are good at, and leave all other things to those, who are better at doing them. Compete to win; do not bother fighting battles that you cannot win. You have limited resources and time—invest them wisely. Don’t waste your time and money.

Agility: The pace of change is mind-boggling today, and it is accelerating. Prepare to adapt quickly to a changing environment. Designs that encapsulate variation will win out over those that entrench how we understand things today. Evolution weeds out those, who cannot adapt to change. Embrace agility or become extinct.

Focus and agility. These two words are worth about usd$130 million to us. You get them for free.

It’s amazing how we have the ability to look back in time. Not just in memories. Not just through archeology. These are only remnants of what actually existed in history. However, the laws of nature have bestowed upon us the ability to actually witness the past in its full glory. In fact, we can see right this moment if we look hard enough as far back as the moments following the Big Bang. And a second later, if we look 3*10^8m further into the distance, we can see exactly the same moment again.

Try to come to grips with the fact that everything you witness in the present has actually occurred some time in the past. Then extend the scope of your observations beyond your immediate vicinity. Look further out and deeper into history. Here and now you are able to see the past unfolding before you. It’s profoundly mind blowing.

Most of my life is spent communicating, despite the fact that I rarely say much. Ever since I read about epistemology and the theory of cognition, I’ve recognized the need to build conceptual models first and notations second. I continually yearn for a precise method of expressing ideas.

All around me, I see people misunderstanding each other. Communication is a shared responsibility. It requires a collaboration between the source and the target.

The source is responsible for organizing his conceptual model. He identifies the distinctive subset of the model that requires expression, and separates it from the remainder of the model that is the foundational context. He structures a presentation for the expression using a notation.

The target is responsible for comprehending the notation. He must decode the notation into the foundational context and distinctive subset of the model that is being expressed. Ideally he decodes exactly the same conceptual model that originated from the source. However, more often than not, the resulting model is different. Communication has failed to faithfully convey the meaning.

Modeling is my life’s work. I do it well. Unfortunately, I am unskilled in developing notations. I must settle on using the notations that others have handed down. For now, I will be misunderstood. And so will you.