SOA in a Nutshell

Service-oriented architecture has emerged as the means to improve business intelligence, innovation and agility, through developing loosely coupled distinct automation logic units. These loosely coupled automation logic units allow an abstraction of business logic and technology.

SOA encourages units of logic to exist autonomously yet not isolated from each other. In SOA the units of logic are known as "services".

Automation Logic

The automation logic components used by SOA comprise of:

1. Messages: which represent the data required to complete some or parts of a unit of work.

2. Operations: which represent the logic required to process messages to complete a unit of work

3. Services: which represent logically grouped set of operations capable of performing related units of work.

4. Processes: which contain and define the business rules that determine which service operations are used to complete a unit of automation. Instances of processes wherein a group of services follow a particular path through the process logic to complete a task are known as activities.

SOA Principles

Key principles in SOA are:

1. Autonomous services
2. Loosely coupled services
3. Services abstract underlying logic
4. Composable services
5. Formal contracts to define information exchange between services
6. Reusable services
7. Stateless services
8. Discoverable services

Software Components

Systems engineers define requirements at various levels, the highest of those levels is the business level, then comes the enterprise level, then the system level, then the component level. For a physical system a component could be easy to identify, how about software?

One way of defining a component in the software world is an active object with clear self-defined interfaces [1]. Active objects are objects with have their own thread of control.

Another definition is that a component is an object written to specification. Components are defined to meet several criteria namely; multi-use, non-context-specific, composable, contained and of independent versioning [2].

So a component level requirement is a requirement that tells the developer the needs that the code shall be able to accomplish.

[1] Hassan Gomma, "Designing Concurrent, Distributed, and Real-Time Applications with UML", Addison Wesley, 2000

[2] http://en.wikipedia.org/wiki/Software_componentry

Applying the Learning-Teaching Style Process to Jump Start Your Novice Engineers

Working as an elementary school teacher is not an easy job. One of the biggest challenges facing an educator is activating and sustaining the student's motivation.

Richard Lavoie in his book "The Motivation Breakthrough" discusses a four-step process which has been effective with children during challenging times. The process is summarized as follows:

1. Do it for the student - By explaining to the student what needs to be done, we then ask questions about next steps. Using common sense and logic the student should be able to explain what needs to be done to solve the problem. During this step the student is not asked to do the work himself, but only be responsive to questions, actively listening and asking questions.

2. Do it with the student - In this step the educator allows the student the opportunity to do part or all of the work with the assistance of his coach. Upon the completion of this step the student will be able to perform the task, or solve the problem on his own.

3. Observe the student - In this step the educator observes the student doing the work. It allows the educator to evaluate the process of the problem solution and not just the final result. It is a great opportunity for the educator or coach to offer suggestions, praise, clarifications and guidance. Upon completion of this step the student becomes a master in the problem or task.

4. Have the student do it - The student is completely independent and not supervised during the problem solving or task implementation. It provides the student extra confidence and the ability to innovate and improve the process and skills involved.

As Chief Systems Engineers we can apply these concepts to novice team members or new graduates. New members could shadow experienced systems engineers and achieve step 1 and 2 through direct interactions during the shadowing process. Delegation allows the senior team member to observe the junior team member and finally a complete turn-over allows the realization of the fourth step.