Web Blog_blogentry_160718_1

New World of Business#

The ultra competitive environment, that we are within, the days of stove pipe organizational structures must be broken down to small reactive teams.

The old Command-and-Control Management model was well-suited for complicated and predictable challenges. Some of these challenges still exist today and may respond to the industrial-era practices that we know so well. However, as the pace of change accelerates, the challenges we face are becoming less and less predictable. Those practices that were so successful in the past are counter-productive in less predictable environments.

To provide some examples, think about these statements: [2]

  • Uber, the world’s largest taxi company, owns no vehicles.
  • Facebook, the world’s most popular media owner, creates no content.
  • Alibaba, the most valuable retailer, has no inventory.
  • Airbnb, the world’s largest accommodation provider, owns no real estate.”
  • Amazon is the largest Internet retailer in the world as measured by revenue and market capitalization, and second largest after Alibaba Group in terms of total sales. The amazon.com website started as an online bookstore and later diversified to sell video downloads/streaming, MP3 downloads/streaming, audiobook downloads/streaming, software, video games, electronics, apparel, furniture, food, toys, and jewelry. The company also produces consumer electronics—Kindle e-readers, Fire tablets, Fire TV, and Echo—and is the world's largest provider of cloud infrastructure services (IaaS and PaaS).
These Organizational Entities are indescribably thin layers that sit on top of vast supply systems (where the costs are) and interface with a huge number of people (where the money is).

The New York Times needs to write, fact check, buy paper, print and distribute newspapers to get their Advertising money. Facebook provides a platform for us to write our own content, and Twitter monetizes the front page of newspapers, which happens to now be the Twitter feed. Our relationships are no longer with the original content Service Providers. Within organizations the same change and similar turmoil is taking place. The monolithic data silos within the organization now need to be shared with not only other organizational silos but even with third-parties.

In the Lean Enterprise, the preface starts off with some quotes:
"Software is eating the world." Marc Andreessen
"In an industrial company, avoid software at your own peril...a software company could disintermediate GE, someday, and we're better off being paranoid about that." Jeff Immelt

Agile, Lean, Cloud computing, Microservices, Functions as a Service, DevOps, Cloud Native#

Are terms you hear about but these Frameworks are all focused to allow the organization to become a more Responsive Organization by adding Business value at an ever increasing Velocity

Monolithic Architecture#

Monolithic Architecture in which functionally distinguishable components (for example authentication, data input and output, data processing, error handling, and the User Interface) are all interwoven, rather than containing architecturally separate components.

Mainframe computing is an example of a Monolithic Architecture.

Over time there are more and more requirements added to the application. At some point the Monolithic application becomes so complex that even a small change causes significant effort as to the interdependencies between the different components within the application. Probably the first component to be refactored from the monolithic application was Authentication. In the mainframe world was the External Security Manager (ESM). (Think RACF and ACF/2). This allowed mainframe applications to at least share user information.

Likewise, the first applications for the PC were also monolithic applications.

Likewise when networking (before the Internet) started, we had Monolithic Architectures and applications.

Authentication was probably the first thing that was refactored was to allow external Authentication Method. This is generally where we are today in many organizations. Many applications, middle-ware, and even some operating systems allow for external Authentication. ( although almost none allow for external Authorization )

And then the Internet happened. And again the first thing that has was abstracted from WEB Applications was Authentication (think OAuth,Social Login, OpenID Connect etc).

Along the way, several things did happen to applications. Model-View-Controller (MVC) is probably the best known. Applications were broken into separate components within the application. We came up with the "Front-End" and "Back-End" developers.. But these components still were all within the same application. They were still for the most part within the same Monolithic Architecture process. (But could be multi-threaded

Now we are at the next phase and we will talk about:

API Economy#

API Economy is evolving out of Responsive Organizations that realize:

At amazon, in 2002, Jeff Bezos issued a mandate:

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Teams must communicate with each other through these interfaces.
  • There will be no other form of Inter-Process Communication allowed: no direct linking, no direct reads of another team's DataStore, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network (i.e. Application Programming Interface).
  • It doesn’t matter what technology they use.
  • All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

The mandate closed with: "Anyone who doesn’t do this will be fired. Thank you; have a nice day!"

Another prime example of industrial-era Organizational practices is General Electric which inspired awe for many of it 126 years:

  • In 1896, GE was one of the original 12 companies listed on the newly formed Dow Jones Industrial Average
  • In 2008, GE was bailed out by the federal government and Warren Buffett
  • In 2011, GE ranked among the Fortune 20 as the 14th-most profitable company.
  • In 2012, GE was listed as the fourth-largest in the world among the Forbes Global 2000
  • In 2017, GE ranked among the Fortune 500 as the 13th-largest firm in the United States by gross revenue.
  • In 2018, GE was removed from the Dow Jones Industrial Average as the stock was down about 55 percent over the past year.

Bounded Context#

Bounded Context tries to define boundaries of our complex domains into business contexts.

Bounded Contexts are important because they allow us to define a ubiquitous Taxonomy that is shared and valid within a boundary.

A Monolithic Architecture application is a Bounded Context in itself. The application must be deployed as a whole. That is, there is one war or exe file that comprises the application.

Likewise, each team or area within an organization is a Bounded Context.

Finance department only exposes some of the activities that happens within their department. Likewise the monolithic application only exposes some of the activities that happens within the application. Even within applications there are Bounded Context. The database is a bounded context that often has dependencies for Consumer of services. If the structure of the database (i.e. Schema) is changed, then any Consumer of services for the data also has to change. The database is said to be "tightly coupled" to all of the consumers as Modify in one requires changes in the other.

Law of Pluralism of Operators and Technologies#

Law of Pluralism of Operators and Technologies although it is specifically IDM it shows that any modern application or system or channel must enable the inter-working of multiple technologies run by multiple Service Providers.

Some application for boating is written to provide as weather as a function of boating.
The original monolithic design the app read the NOAA weather reports and stored the data in a database each day. They then retrieved the data based on Zip Code from their database for each user.

Then it was discovered that a weather provider service could provide them with already formatted data through an API.

They would no longer need to know about the details of the weather data, or store the data and the data was provided in real time. The application went from using data within a "tightly-coupled" datastore to getting data from a RESTful API. In this case the Bounded Context of the Weather Data was abstracted or refactored from within the Bounded Context of the application.

This implies any application written in in any Programming language could utilize the Weather API by using a RESTful (API).

Business value#

The real purpose of all of Information Technology is to provide business value. Business value is to enhance the customer's experience.


Agile methodologies were developed to allow adding business value in a quick and efficient manner to allow the organization to adapt quickly as things change.

Automatic and Continuous Delivery/deployment is a Agile Principle.

Agile is in direct contrast to Big Design Up Front (BDUF) which is when you make a design at the beginning of a project. Usually this is the point where you actually know the least about what you are designing.

Big Design Up Front (BDUF) vs Emergent Design#

Emergent Design is where solution will emerge little-by-little as you progress through the process, typically using very short Red Green Refactor cycles.

Emergent Design starts with a rough idea about the Business value you want to deliver, and defers most of the design the decisions until you know more. (aka Last Responsible Moment)

Most of us have seen many times in these multi-month (or multi-year) projects where a decision made at the beginning of the project, which at times, was known to be a bad idea to go that way when the implementation was being done? Yet the when discovered, the now seemingly foolish design needed to progress because we had to meet the timelines.

Architecture within Information Technology is hard#

Architecture within Information Technology is hard. The requirements shift more rapidly than they do for architects who design and build buildings—as do the tools and techniques at their disposal.

The things we create are not fixed points in time. Once launched into Production tier, the software will continue to evolve as the way it is used changes. For most things we create, in Information Technology it is accepted that once the software gets into the hands of our customers we will have to react and adapt, rather than it being a never-changing artifact. Thus, Information Technology architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.


Microservices are an approach to distributed systems that promote the use of finely grained services with their own life cycles, which collaborate together.

Because microservices are primarily modeled around business domains, they avoid the problems of traditional tiered architectures.

Microservices also integrate new technologies and techniques that have emerged over the last decade, which helps them avoid the pitfalls of many service-oriented architecture implementations. Microservices did not just get invented, but rather emerged from a world of technologies which came before them, such as:


All of these concepts are to deliver Business value on at a faster pace so that the Organizational Entity is more Responsive to Customers

More Information#

There might be more information for this subject on one of the following: ...nobody