Most operations require privileges. Did you forget to login? - Login
A brief History of Software
With SOA, Microservices, Semantic Evolution and Artificial Intelligence Components
In the beginning was the Word...
One of the earliest known civilizations was Sumer, in the Uru region of the Middle
East (now Southern Iraq), about five thousand years ago.
The Sumerians soon dissolved into the Chaldeans, Jews and Babylonians, but not
before developing a system of numbers and writing, which is the foundation of the
systems that we use today.
The First Software all-in-one Programs. Many years after the Sumerians, the
first computer was released: the Electronic Numerical Integrator and Computer
(ENIAC) in 1946. Software programs for the early computers included everything:
the hardware drivers, the data for the software, the business logic required to
run the software.
these pieces were tightly integrated and mixed together in order for the
program to work. In the beginning of my own career, I wrote programs like
these, first in binary code, then in Assembly, and later, as software
progressed, in programming languages such as FORTRAN, COBOL, C, and FORTH.
Object-Oriented Paradigm (OOP) and Layered Architecture. It took the
industry several decades to transition to the Object-Oriented Paradigm (OOP)
and Layered Architecture. While the early software programmers had to write
hardware drivers, programs that communicate with the computer hardware, telling
the hardware how to work properly, the later programmers did not have to worry
about that part of the program. Operating System and Database vendors took over
the hardware driver and database programming, leaving the software developers
to focus on the application layer, creating better-working, more complicated
Service Oriented Architecture (SOA). SOA shifted development focus to
business functions and related services, with the idea that applications must
be designed as reusable connected services. This idea taught programmers to pay
more attention to business specifics and build versatile pieces of software
that could be used for many applications.
Microservices. Microservices further
helped to more precisely define services while fighting for service
independence against application flavors. Independence is expensive. Getting
rid of application specifics, developers decreased �the essence of a service while
increasing the frame of the service packages.
services and RAML. Application
Programming Interface (API) became a standard way to introduce services.
RESTful API Modeling Language (RAML) and Data Sense by MuleSoft provide a semantic flow of
technical descriptions of API, making it easy to introduce and
manage services and microservices.
these naming conventions look good for one business, they might have different
names in another business. The next step is to prepare these services working
across several businesses with different business dialects. This can be done
via a canonical semantic data schema, or more precisely via the semantic graph,
a semantic integration layer.
A Semantic graph can
represent a business domain, providing canonical object names with their
synonyms and connections between objects and their properties. The semantic
integration layer serves as a formal data dictionary for choosing the names,
which will work across multiple business dialects in the same business domain.
illustration below tells the story of the integration evolution, from
point-to-point to centralized integration with Enterprise Service Bus (ESB),
and further to canonical interfaces with the semantic layer, which connects
multiple business dialects.
Enterprise Services with AI components
Artificial intelligence can mean many things. I focus
just on one. Computer programs are becoming more helpful. They start working
for us not just as stupid machines, but almost as partners.
In partnership, it is extremely important if partner
understands your intentions and plans. This is a big "if", which is gradually
dissolving into "how".
A semantic graph is the mechanism to describe
associations or connections between different objects
with the idea that this is the richest representation of a knowledge domain,
often called Ontology.
This might be a good point to discuss the difference
between Taxonomy and Ontology.
Taxonomy collects keywords to describe content. Ontology
uses more powerful methods to create more detailed meta-data models. In
addition to collecting the key vocabulary, ontology picks up on the
relationships between the keywords effectively building a semantically rich and
much more meaningful model of the content.
For example, in the sentence "Yefim Zhuk was born in
Russia", taxonomy would only use two keywords
from the sentence, the name and the place. Ontology would also include the
relationship between the two keywords and create a graph representing the
content in a greater level of detail. This graph can be extended and later used
for querying, in other words for asking
questions related to this information, such as
"what is Russia". . . .
By being more formal and detail oriented, ontology helps us elevate information to
the next level understood by computers.
And that fundamentally helps a computer to understand what service we are looking
for, what workflow and application we would like to build and etc.
For example, in a semantically rich environment,
there is no need for complex monitoring tools. The service names and
descriptions as well as application messages are self-explanatory and directly
tied to the semantic execution model.
Application messages can describe as many properties as
necessary with the idea that each property is defined in the semantic model.
The messages can tell the story about WHEN (time), WHAT (description of the
event), WHERE (system or/and service name), HOW Serious (type), HOW to fix (recovery
action), and WHO should be notified.
A relatively simple semantic listener program can
understand and act upon these messages.
This approach, when it is consistently used across the
company and industry, will create smaller, smarter, and inexpensive semantic-sensitive
tools to monitor and manage service operations. The same message will become a
valuable record in the root cause analysis and recovery processes. Such records
can be RDF-formatted. These RDF-formatted records-messages can represent the "situational
Knowledge-Driven Architecture*. The challenge, still, is the gap between
the business and the programmer: business language is very different from XML,
service terms, and programming languages. Knowledge-Driven Architecture is a
new way of architecting systems based on business rules and scenarios. This
step requires a new type of a developer - one who understands the semantics of
business and can clearly express new ideas bridging the gap between the
software, and its actual, practical use in the corporate or research worlds.
Today we can see new software frameworks, such as Google
Robot Framework or Cucumber, discussed in the review http://TopDevelopmentSkills.com.
Growing importance of communications skills is gradually
changing demography of a development crowd.
Women, who naturally communicate more than men, have an
Find more about the upcoming changes in management: http://womenandmen.us
In the beginning was the Word ...
1. Cycorp combines an unparalleled common
sense ontology with a powerful reasoning engine and natural language
2. Financial Industry Business Ontology
(FIBO) standard, http://www.edmcouncil.org/financialbusiness
3. Distributed Active Knowledge and Processes,
Jeff (Yefim) Zhuk / Yahoo, US Patent, https://patents.google.com/patent/US7032006
4. Knowledge-Driven Architecture, Yefim Zhuk, Streamlining development
and driving applications with business rules and scenarios, US Patent, http://www.google.com/patents/US7774751
5. The book online, IT of the future, http://ITofTheFuture.com, focuses on practical steps to
transition the current IT to a unified Semantic Cloud Architecture.
6. Adaptive Robot System with Knowledge-Driven Architecture,
Yefim Zhuk, On-the-fly translations of situational requirements into adaptive
robot skills, US Patent, http://www.google.com/patents/US7966093
7. MuleSoft Enterprise Service Buse
8. Collaborative Security and Decision Making, Yefim Zhuk /
Boeing, transforming a beautiful idea of collaborative security decision making
into a working system, Patent in the US and 15 European countries, http://serviceconnect.org
9. Rules Collector system, Yefim Zhuk /
Boeing, Transforming "tribal knowledge" into formal rules to drive applications
and business processes, US Patent,
10. Top Development Skills - review, http://TopDevelopmentSkills.com
11. Internet Technology Summit Program � integrated software and knowledge engineering, http://InternetTechnology.us
12. http://FixingEducation.us - Changing formula of education
13. http://WomenAndMen.us - Upcoming gender changes in IT management