Jump directly to study ... or read below first.
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.
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". . . .
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 ...
Internet Technology University | JavaSchool.com | Copyrights © Since 1997 | All Rights Reserved
