New World of Business#The ultra competitive environment that we The days of stove pipe organizational structures must be broken down to small reactive teams. Our old Command and Control operating 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.
- 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).
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
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 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 now the Internet. And again the first thing that has was abstracted from WEB Applications was Authentication (think Social Login 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 process. (But could be multi-threaded)
Now we are at the next phase and we will talk about:
- API Economy
- Bounded Context
- Law of Pluralism of Operators and Technologies
- Business value
- Big Design Up Front (BDUF) vs Emergent Design
- Functions as a Service
- Internet is the dominant platform
- Organizations Must add constantly Business value
- Organizations Must deliver Business value faster
- 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 data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- 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 U.S. 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.
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 contexts. The database is a bounded context that often has dependencies for consumers. If the structure of the database is changed, then any consumers for the data also has to change. The database is said to be “tightly” coupled to all of the consumers as modifications in one requires changes in the other. As an example, as Identity Specialists we need to know a lot about IDM. However, the folks writing a Web application only need to know how to use what we provide them. So, in our organization we have two Teams. IDM Team and the Web development team. Each of these teams represent a bonded context.Red Green Refactor cycles. Emergent Design starts with a rough idea about the Business value you want to deliver, and defer most of the design the decisions until you know more. (Last Responsible Moment)
Architecting 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, 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.
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:
- Service-oriented Architecture (SOA)
- Domain-Driven Design
- Continuous Delivery
- On-demand virtualization
- Infrastructure automation
- Small autonomous teams