CertificationArchi

Integration Architect Certification

 

OpenESB certification for architect is one of the most complete and hands-on certification on service oriented integration. It requires a great understanding of integration architecture, a hands-on skill on OpenESB. After passing your OpenESB certification for developer, you will be asked to design in detail a full integration project.
You currently work on large integration projects with service oriented technologies for many years as an architect or senior developer. You require your skill and cognition to be validated and recognized by your peers, Pymma proposes you a challenging certification on Service Oriented technologies and OpenESB.
Passing OpenESB certification for architect validates your skill and knowledge on Integration, architecture, service oriented design, integration technologies and evidence you are able to use your knowledge in a tangible project.
The certification takes place in three steps:
•    Test your theoretical knowledge on Architecture, integration, service orientation and OpenESB
•    Design and specify a full integration project with OpenESB
•    Upgrade your specification in a short time and prove your design is agile and upgradable
If you success to these tests you will pass one of the most challenging test on integration and service orientation and will be a Certified Architect for OpenESB. No need to say that this challenge will be useful for any other integration technologies and products.
 
Three steps to test your knowledge


1-Questionnaire on service oriented integration and OpenESB
The first test you must pass is a set of questions on a large scope of on integration knowledge, SOA technologies and OpenESB. The test lasts 90 minutes for 60 questions. The passing score is 70%. Language: English.


2-Full integration project
For the second step of the certification, you have to design, document a full integration project and provide specification for OpenESB implementation. Pymma sends to you business requirement and technical specifications to the applicants. Your work will be assessed on:
•    Specification understanding
•    Design and documentation quality.
•    Best practices usage
•    Reliability
•    Scalability

 

3-Upgrade your project
If you fulfil the requirements and follows the best practices in integration, you will be asked to modify your project and implement new requirements in a short delay. Once the modification and the evolution implemented, you send us back the project. We will evaluate your ability to implement easily evolution and new features. If you success to this last challenge, you will pass the certification.
More information on OpenESB Certification Architect, please contact us at: This email address is being protected from spambots. You need JavaScript enabled to view it.

Microservices and SOA: The antagonism is not technical but..

With all my respect, I think that if Martin presented good arguments in his speech but did not give the real difference between microservices and SOA. Before going forward, it is interesting to notice, that concept of microservices had a prompt success in large companies first. Surprisingly, from its inception, the microservices have been used to deprecate the ‘SOA’ concepts, even if the gap between both techniques was very thin or in many cases, null. Here cHere ome a few simple questions: Why did some people try to oppose the two technologies that are so similar? Why did they want to push SOA to oblivion while they use exactly the same principles and technologies than SOA? Martin provided in his lecture, many trails to reply to the questions, but I came to a different conclusion. If we can understand this antagonism which is not based on technical differences, maybe we will understand the differences between SOA and microservices. To understand this antagonism, the SOA Manifesto, the abstract of the SOA philosophy, must be read once again. In the manifesto’s introduction, it is written:

 

Through our work, we have come to prioritize:

Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection

That is, while we value the items on the right, we value the items on the left more.

 

In this introduction, the first priorities were not technical challenges, but the Business value and the Strategic goals. When you are concerned about Business value and Strategic goals in your project, it is in your interest to involve the most capable to define what the Business values and the Strategic goals are. This means that the SOA philosophy requires the business to collaborate and more annoyingly for IT teams, it needs a kind of leadership from the business, because Business value and the Strategic goals definitions are more accurate and efficient when defined by business people.

For years, business and IT lived in two different worlds. The communication between them was focused on budget, cost, business specifications and nothing else. It was OUT OF QUESTION that the business interfered in the IT works and the later in the business prerogatives. This antagonism between the two entities lasted for decades. However, 10 years ago, for the first time in IT’s history, a new philosophy puts the business goals and the long-term strategy as a priority. For the first time, IT people had the willingness to involve the business in the IT development process. If the business never understood what was a function, a component or an object, for the first time, SOA pushes forward a concept named ‘Business Services’, which had a coarse enough granularity to be understood and used by the business. So, for the first time, business and IT could exchange, and work on similar concepts.

Unfortunately, especially on larger projects, consulting companies found in this opportunity a way to impose expensive business consultants and management, to IT teams. I remember taking part in numerous meetings with high-rate business consultants who didn’t have a concrete idea of what a service is, but could explain through wonderful PowerPoints, how SOA could help us to design and develop them. Pushed by the C level management and the consulting companies, a useless business predominance replaced a required and fruitful collaboration between both parties. A reaction, from the IT, to stop this predominance occurred and has been named ‘Microservices’.

It is interesting to analyse, why this reaction took the name of ‘Microservices’ and not ‘Light Services’, ‘Agile Services’ or ‘Reactive Services’? The prefix ‘micro’ before ‘services’ that suggests services with fine granularity, does not make sense since neither SOA nor Microservices define a standard granularity for a service. Often services defined by microservices developer have a coarser granularity than the ones developed by SOA developers.  So, what is the symbolism behind the prefix ‘micro’ and why it was so pleasant and attractive to IT people. Wise men explained that a name, often contains the finality of the named entity or concept.

As noticed above, one of the SOA aims, was to promote Business Value and Strategic Goal. Consequently, this aim was to define services comprehensible by the business and coarse enough to be useful for business process definition. In the way, IT things, the services understandable and used by the business have a coarse granularity. In reaction, IT people created the concept of ‘Microservices’. The objective was to define small services where the granularity was too fine to be in the business scope. So, with microservices, the business cannot interfere in the IT work anymore. That is the opposite of the SOA initial philosophy.

Actually, there are no technical differences between SOA and microservices, but their fundamental difference is the interest in a relationship between business and IT.  You can find this idea coming from a day to day psychology, but to be convinced, notice that neither the technical papers, nor the blogs, nor the conferences about microservices consider business concerns or simply talk about a link between microservices concepts and business concerns. In reaction to the business predominance created by the bad use of SOA philosophy, business concerns and strategic goals have been erased from the microservices manifesto and developer objectives.  

Picture2

Figure 3:Business vision of SOA and microservices


The border line between SOA and microservices is simple to understand and is defined by the IT wishes to work with the business. Through this dimension, Microservices is not a subset of SOA but a different domain.

Of course, the real life is not black and white and many microservices people collaborate with the business and some SOA people don’t. Here, I’m not talking about people but the history, the philosophy and the concepts that generate the microservices wave. It is good to put names on things, and understand where SOA and Microservices are different. Up today, I did not find similar point of view expressed yet. I could be completely wrong, but I think, we are reluctant to this idea which associates microservices with the 80’s-90’s mentality and is not politically correct. So, it is difficult to express it before an IT audience who feel enthusiastic about microservices. Without this truth, we couldn’t understand the increasing separation we notice today between IT and Business.

This said, everyone knows that the future of IT is to work in harmony with the business and allows it to be involved in service and process definition. We could wait for a few years, the next swing of the pendulum and then be thrilled by a new buzz name that promotes a collaboration between IT and business. Or simply, whatever denomination we want to use for the same technology, we can retrieve a peaceful and successful collaboration that occurred a few years ago, when a strong respect existed between business and IT. That would certainly be the best choice for all of us!