What are you up to?

Study Software Development and Artificial Intelligence Applications
Explore Enterprise Services
Semantic Search

Should we be scared of losing jobs to automation?

Yes and no. For several professional areas the time for "profession for life" is over. Quick learner is the most important profession.
AI opens new horizons that we did not see before. We recognize new opportunities and start doing new things, things that we could not even imagine today.
This spiral leads to even more opportunities - translated into more jobs, which require new skills.
Increasing productivity means improving quality of life, especially for those who acquired the skills.

The bottleneck is our ability to quickly learn and change. Can traditional education do the trick? Apparently not.
We need and we can change the formula of education.


Internet Technology University (ITU)
A patented system, which includes AI components, Accelerates Sharing Knowledge with Conversational Semantic Decision Support - Ask CSDS.
The system helps any subject matter expert to transform her or his knowledge into well-structured materials effectively empowering a training process.
The system also tracks a student engagement at each point of study taking into account individual learning differences.

If this sounds like magic and you would like to become a magician: join us!
ITU teaches AI development skills - the skills that are in the highest demand today. And we teach AI with AI.

Our AI Training Platform (work-in-progress) allows more people to quickly adapt to changing markets and move from low to highly-paid jobs. These skills are going to be a common ground for many professions.
Any person who understands perfectly well her or his daily routine can translate this knowledge into automation ... after learning the art of translation.
Even in the software development we came close to another turn where a new set of skills is becoming priceless.
While almost every profession will be enhanced with a fraction of AI, the most complete spectrum might be found in software, which produces AI instruments and services.
So far, software serves as a platform for AI. Let us take a closer look at its transformation over a brief history.

A brief History of Software ... with SOA, Microservices, and Artificial Intelligence

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.

All 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 programs.

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.

API-based 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.

While 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.

The 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". . . .
Ontology example
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 awareness" factors.




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 the advantage here. Find more about the upcoming changes in management: Women and Men in IT and management

In the beginning was the Word ...