Current Topic: 7.3.1.From Structured Programming to Layers and SOA
You have a privilege to create a quiz (QnA) related to this subject and obtain creativity score...
From Structured Programming to Layers and SOA
Good old times of programming "all-in-one" ...
Do you still remember good old times when a programming code included hardware drivers, data management, and business logic, all together? We would call it spaghetti today, but at that time this was the only way to make it work. From zeros and ones we moved to assembly language, the first step in a semantic evolution of art of programming. And then software started its ascent over the ladder of architecture layers.
Architecture layers
Operating system developers, such as Sun Microsystems (currently Oracle), Microsoft, Apple, and several more took care of the system layer. Database vendors, such as Oracle, Sybase, Microsoft, and several more took care of the database layer. Most of programmers became application programmers, who built the application layer on the top of the giant shoulders mentioned before.
Application monsters
Divided by corporate barriers and working under time-to-market pressure, we replicated data and application functions and produced software that is neither soft nor friendly, lacks flexibility and teamwork skill, and is barely ready for integration into new environments. By producing "more of the same" we actually increased entropy and slow down the pace of technology [1].
Long projects and inflexible, fast-aging applications (that cost a fortune to maintain!) created more pressure for a better Business ? Technology Convergence. Developed in isolated departments, applications often duplicate business functions and, with their growing number of features, become unmanageable and unpredictably expensive monsters.
Business changed their appeal to IT and development - it is too slow.
It takes multiple layers and teams to translate business requirements into Boolean Logic and bake it together with many old and new functions.
The resulting cake is too firm in spite of its name - Software.
Service-oriented architecture (SOA)
SOA is a software architecture style that focuses on service components (services) that are reusable across multiple applications and enterprises. While Service-Oriented Architecture (SOA) is an old concept, current standards and technologies have paved the way to add efficiency and gain strategic advantages for the enterprise to quickly introduce new, or change existing business features.
SOA helped translation of business products and services into architecture artifacts, starting from Business and Product Architecture Views and following with the Service Views, then Data and Infrastructure Architectures.
SOA promised to simplify the transition from business vision to software development. This promise is not yet fulfilled. There are still semantic and process gaps that need to be covered. And software continue its semantic evolution. [2]
Service types and layers
While the focus is on the business services, there are more service layers. We can easily distinguish between simple and composite service types, but it is even more important to recognize the different service layers.
Note that everything starts from the Business Architecture. Business needs Product Lines. Product Lines consist of Products, which in their turn are collection of Features.
At this point a developer can map Features to Business Services, creating a Business Layer of services.
The hierarchy of service layers is very visible.
Business Layer, such as Order or Customer services;
Utilities, such as Single Sign-On, Search, or Scheduling services, and
Data Layer services that can be called up from Business or Utilities services (but not directly from applications!).
Was it clear so far?
Business services, such as the Order service, are usually named after the business functions they represent. The Order service is usually implemented as a service orchestration or a sequence of composite services responsible for specific processes.
Process services, such as Single Sign-On, Search, Scheduling, and more in their own turn consist of Data services and Utility services, which are often called System services as they specialized in accessing specific systems and data sources.
Sample
Note that everything starts from the Business Architecture. Business needs Product Lines. Product Lines consist of Products, which in their turn are collection of Features.
At this point a developer can map Features to Business Services, creating a Business Layer of services.
The hierarchy of service layers is very visible.
Business Layer, such as Order or Customer services;
Utilities, such as Single Sign-On, Search, or Scheduling services, and
Data Layer services that can be called up from Business or Utilities services (but not directly from applications!).
Business services, such as the Order service, are usually named after the business functions they represent. The Order service is usually implemented as a service orchestration or a sequence of composite services responsible for specific processes.
Process services, such as Single Sign-On, Search, Scheduling, and more in their own turn consist of Data services and Utility services, which are often called System services as they specialized in accessing specific systems and data sources.
The art of designing service layers for an application and across enterprise is called today Microservices. [3]
Assignments
1.Check the Following References:
1.1 Integration-ready architecture and design, Jeff (Yefim) Zhuk, a book on software and knowledge engineering, http://www.amazon.com/Jeff-Zhuk/e/B001H6O9IU
1.2 IT of the future, Jeff (Yefim) Zhuk, a book on transitioning to Semantic Cloud Architecture, http://ITofTheFuture.com
1.3 Building Microservices, Sam Newman, http://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358
