Software Semantic Evolution and the Next Step: Part 1

Learn more about Yefim (Jeff) Zhuk. Click here to read Part 2, Part 3, and Part 4 of this post.

SOA and Microservices

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 or more previse – operating 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!).

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]

Microservices and API-led connectivity by MuleSoft

Imagine that as a developer you have access to multiple services developed independently and your intention is to select those that provide necessary functionality and connect them into a working application. If you think that it is easy, think again. There is a need for well-structured and well-known APIs, the need that was not well addressed so far.

API-led connectivity by MuleSoft is a good step in that direction. MuleSoft promotes RESTful API Modeling Language (RAML) and developed its own set of MetaData and annotations known as DataSense. Under RAML and DataSense umbrella services are not only re-usable, but can be easily discovered alone with their parameters.

Stay tuned for Part 2 in this blog series.

References:

Integration-ready architecture and design, Jeff (Yefim) Zhuk, a book on software and knowledge engineering, http://www.amazon.com/Jeff-Zhuk/e/B001H6O9IU
IT of the future, Jeff (Yefim) Zhuk, a book on transitioning to Semantic Cloud Architecture, http://ITofTheFuture.com
Building Microservices, Sam Newman, http://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358