You are here:  Home  >  Data Education  >  BI / Data Science News, Articles, & Education  >  BI / Data Science Blogs  >  Current Article

Software Semantic Evolution and the Next Step: Part 1

By   /  October 28, 2015  /  10 Comments

Learn more about Yefim (Jeff) Zhuk. Click here to read Part 2Part 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

appmonster-image-102715Divided 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.


  1. Integration-ready architecture and design, Jeff (Yefim) Zhuk, a book on software and knowledge engineering, http://www.amazon.com/Jeff-Zhuk/e/B001H6O9IU
  2. IT of the future, Jeff (Yefim) Zhuk, a book on transitioning to Semantic Cloud Architecture, http://ITofTheFuture.com
  3. Building Microservices, Sam Newman, http://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358
  1. MuleSoft, API-led development, https://docs.mulesoft.com/mule-user-guide/v/3.7/publishing-and-consuming-apis-with-mule
  1. RAML Organization, http://raml.org/
  2. MuleSoft, DataSense, https://docs.mulesoft.com/mule-user-guide/v/3.7/datasense

About the author

Chief Architect at ITS, Inc., Yefim (Jeff) Zhuk, worked as Director of Enterprise Architecture at Sallie Mae, consulted Boeing and other corporate and government agencies in SOA and knowledge engineering, shared his expertise at Java One, Semantic Tech, and Boeing Conferences. In his books, patents and publications Yefim described a new field of Integrated Software and Knowledge Engineering. The methods and prototypes described him as Business Architecture Sandbox for Enterprise (BASE) and Conversational Semantic Decision Support place new technology seeds in the current business ground, helping transitioning to rule-based applications and Semantic Cloud Architecture.

  • Lena

    Very interesting. And where
    are you going with that

  • Christina H

    I found this blog very interesting and
    informative. Good job!

  • Jane

    Jeff, I am a programmer. I currently study advanced programming subjects at http://javaschool.com
    Reading your article, I wonder if in the future we will see a different kind of developers.
    Developers who does not know programming languages, but has the skills to integrate applications from existing services.
    What do you think?

    • Jeff_Zhuk


      I think you are on a very interesting topic.
      Who are new developers? Which skills are becoming crucially important for rapid development?
      Yes, there are integration architects and developers who focus on integration. But so far this is just another tribe of programmers. We definitely change the way of designing and modeling. And this will change the demography of development. But this is another subject…

  • Jeff_Zhuk


    >And where are you going with that?

    Good question! How software is evolving? What will become Information Technology in 5, 10 and 15 years? What should we learn today to be one step ahead of the game and be in demand tomorrow? I often have similar questions from my students. I try to address them in my book http://ITofTheFuture.com and in the following postings on this web page. Life makes its own corrections and nothing goes exactly as predicted. And a single person can see and influence just part of that multi-dimensional story. This web site follows one of the most promising software directions consistently growing attracting more talents. Come here and read more stories. (Plan to post the next part tomorrow or next week.)

  • Don

    Interesting article. What are your thoughts on why the promise of SOA
    hasn’t yet been fulfilled? Is it that organizations haven’t used SOA to
    its full potential or until now we’ve been missing the key tools to
    connect all of the parts?

    • Jeff_Zhuk

      Don, I think we were naïve enough making a
      big leap. We thought that by giving to business thousands of services, we actually providing the keys to applications.

      Unfortunately these keys could only unlock our technical lockers. Business has little interest to these lockers. Business operates with natural language and so far we, software developers, where in the chain of translations from business language to machines.

      This is slowly changing and computer programs become smarter as we help them. Still the last mile will be done by business itself.

      This will be possible when computers with Conversational Semantic Decision Support (CSDS) will be able to understand us or at least ask a good clarifying question.

      Then, the computers will really start learning. Learning from data is a statistical game. (It is still a fair game!)
      Learning from people enables computer partnership!

  • Tony Santillanes

    SOA is a software architecture style that focuses on service components (services) that are reusable across multiple applications and enterprises. Based on this, Service-Oriented Architecture is a concept that requires that the services follow well defined and proven Industry Standards. But, who should be in charge of developing and maintaining those standards? Should this be controlled by Government, Private Business or some independent standards organization or a combination of all?

    • Jeff_Zhuk

      The standards are developed by standard committees with participation of major players of the industry. Of course, each player tries to bend the standard its own way and the result is a set of compromises. Developing standards takes a long time, often years. In the process, massive communications with technical details sometimes shadow business goals, which can be lost in translation. Semantic evolution hopefully can lower the technical barriers and keep business side closer to the surface.

You might also like...

Tackling the Challenge of Transforming Unstructured Data into Actionable Intelligence

Read More →