Roger van de Kimmenade Blog

Pages

2015/05/16

Today i received a mail from one of my Blog readers. I think it is a general question about becoming a SOA architect and therefore i post his question to my blog, so that anyone can help him.
I will also do my share.

Mail:Hello Roger,

I came across your blog and it is pretty helpful for individuals who are pursuing on a career path in SOA and integration area.

I myself have been in the same path since the past 5 years associated with the iWay ESB. I am looking into strengthen my skills and grow into a role of an SOA consultant/Architect after having dealt with a variety of SOA based scenarios in the organizations where i have worked. But i have always found it challenging when we go into the job market as with many ESB tools in the market, its tough to market one self for that particular position as people will be looking for individuals having experience in the their own esb tools.

Even though the underlying functionality and concept is the same for every tool, still its tough to convince the companies to hire.

So how do i go about it and what sorts of skills should i pursue if i am looking to grow into as an SOA and Integration Consultant. I am looking to pursue the SOA Architect based certification from SOA School. More Knowledge regarding SOA i can gain from these certifications definitely, but how do i gain experience in the same if the industry keeps asking for experience on other tools.

I was introduced to iWay from my first company and initially worked as a part of the support team and slowly grew into a developer's role and from then on i have been building my experience working on various integration scenarios using the iWay Service bus. I do indeed want to branch out and get to know how other industry based esb and etl tools handle these scenarios.

I would be grateful to you if you could guide me with the same.

Regards,

Ravi

My first reaction is: a tool is just a tool. Anyone with good skills can learn a tool. Another oneline: a fool with a tool is still a fool. And what i mean here, is that you have to know the concepts of doing SOA and integration, before you can use the tool correctly ! I would rather hire a consultant with good conceptual knowledge and some practical knowledge with a tool.

The challenge is to map that conceptual knowledge to the implementation of the tool !

Examples:

* Use of a Common Data Model

* Use of eai patterns (i.e. store-and-forward, data-mapping)

* What to implement on the ESB and what to implement into a BPM tool

* How to expose the services (REST/XML/JSON/WebService)

* How to make the ESB artifacts testable

* How to divide the ESB implementation into manageable packages

* How to deal with technical and functional errors

* How to monitor

* What security is needed

Etc

With these skills you will become a far more valuable consultant, than just knowing the gritty nitty details of the tool....

2014/09/13

I currently work for a customer that wants to expose its "services" to partners and other external consumers. They do not want to build websites themselves anymore, but instead have the services published and used by partners. So how can this be done?

Always curious and looking for good solutions i started to think about this.
I saw one of the following options:

Just expose the (web)services through a web gateway and use http basic authentication over SSL for security

Make REST adapters and expose those

Requirements

However soon i also discovered:

Consumers have to be managed. You have to manage the client credentials. For a few consumers this is doable, but for a couple of hundred or thousands this can be cumbersome

Consumers have to find the services somewhere. What is the functionality of those services? Is it soap or REST based?

Consumers want to test the services within a sandbox before actually using them

As a service provider you have to manage the life cycle of those services. You can not just make a service obsolete, because clients may still use that version

As a service provider you do not know how many times the service is used. You may want to throttle the usage, based on i.e. the clients or the services.

The services may also be used internally (SOA based services) and these services may be different. Internal maybe may use more data than external. How do you handle this?

As a service provider you want to expose services using different technical interfaces. For example through REST, soap or maybe even JMS. So you need (data) transformation functionality.

Functional components

The more i read about it, the more i came to the conclusion that API Management might be a good solution for this company. Such a platform (or product) comes with basically the following functional components:

Portal ConfiguratorAs a service provider you publish the APIs (services) and the documentation.

API ConfiguratorWithin the API Configurator you can define the exposed services and the integration with your backends.

Traffic ConfiguratorHere you can define and monitor the security policies of your APIs.

Developer PortalHere the clients of your APIs can search for APIs and test them within a sandbox environment. Here the consumers can subscribe for APIs as well.

Traffic ManagerAll API calls run through a API gateway to canalize the traffic. Here the API keys are checked against the policies. May this user actually use this API.

Product selection

The next step in the process is to actually select a product. Because the API Management products are fairly new, this selection can not be based on my personal experience with one of the products. I did two things:

* Read a lot about API Management on the internet

* Talked to other people with more practical experience with products

So what to look for when selecting a product. This depends of course on the functionality you would like to have and the priority and weight of those requirements.

Example: WSO2

Let me first say that i do favor WSO2 perse, but it is an open source product that is already very mature with its API Management product. It has more components that can be integrated as separate components. So whatever you want to use, you can plug in.

2014/03/21

Yesterday i visited the OpenText Innovation Days in Eindhoven. This event was held in the Evoluon, which in the early days was an exhibition hall for future products. This was the first place where i ever listened to a CD. Nowadays it is a nice conference place.

The event was all about data / content / information in other words Enterprise Information Management (EIM). This is understandable because there is where OpenText is at its best, but due to some recent acquisitions they have a nice complete portfolio now to help customers innovate and be agile.

Project RedOxygen

OpenText has done a lot of acquisitions lately and the project RedOxygen is integrating all these produkts, so that consistent and integrated suites are developed. This leads to the fact that all suites will have the same look-and-feel eventually. The suites can integrate easier with each other. For example with the AppWorks component suites are accessible through a RESTfull API.

Suites

OpenText has a number of Suites that helps bringing the right information to the right person at the right time to the device wanted by the users. These are the:

Process SuiteThis is the suite that brings it all together using BPM, Case Management, Cloud and integration.

As my interest was mainly in process suite, i attended most of the process suite breakout sessions.

Process Suite 10.5 launched

On the 19th March the OpenText Process Suite is officially launched during the OpenText Innovation Days.
As described in one of my previous blogs the suite contains a couple of new components compared to Cordys 4.3 (Note that all OpenText Suites have the same version number now).

Some new exciting components are:

AppWorksThis lets you integrate more easily with the other suites of OpenText from within your workflows, BPMs or case management

Process Component LibraryTo give you a quick start with developing you can use a lot of ready-to-use components right out-of-the box.

Case Management ApplicationThis is a ready-to-use application that sits on top of Cordys, thats gives you a full blown application, that only needs high level configuration.

Process ExperienceThis is the HTML5 unified interface to give Cordys a more flashy look-and-feel. In the past the UI (XForms) of Cordys was one of the weakest features. A transition has been made to make the UIs HTML5. CAF and XForms is still also used but in the future this will all be migrated to HTML5.

BPM EverywhereThis component gives you the Social and Mobile features that can be integrated within your processes. Hope to see more on this soon.

The whole suite can be retrieved under 1 license (excluding Process Intelligence). There are also some add-ons: Process Intelligence, ProVision and Capture Center. The Cloud Provisioning (CCP) is separately licensed (just like currently is the case).

2014/02/16

I see it in a lot of projects but also I see that it is handled just like testing in the beginning: "oh we estimate some extra days and we also go Mobile !"

Of course this is not the case, it can be a project on its own.
There are a lot of choices to be made, some of them are:

Which mobile platforms do we have to support?

What are the performance requirements?

Do we want to develop once, run anywhere?

Do we want to use native functions of the mobile OS?

What I also see, is that more and more BPM/Integration platforms are going to support it.

But then again the Mobile experience is somewhat different than the Browser (and Desktop) experience.

So depending on the requirements of the Mobile App, the platform can suffice or not.

I will shortly describe some platform examples.

OpenText Assure

This is a BPM platform that supports Mobile. However the UIs are running within the browser app of the mobile device. The advantage is that it is developed once, and runs on the desktop and iOS, Windows and Android mobile devices. The consequence is that no native functions can be used.

OpenText Process Suite

This is a BPM platform that supports mobile application development. The following picture gives an architectural overview.

The architecture uses some open source frameworks to implement mobile apps.

Oracle ADF Mobile

Oracle Fusion has extended its Fusion stack with ADF Mobile. This framework is also based on open source frameworks.

Tibco Silver Mobile

This is a development platform to develop mobile apps. It adheres to the principle develop once, run anywhere.

Conclusion

The development of Mobile apps must not be taken lightly and must sometimes be seen as a separate project. Most of the platforms in the field have separate development environments for it and can be developed as separate apps next to the normal UIs.

2014/02/10

Introduction

I wanted to know more about DevOps because I agree with the fact that we need to coorporate more and remove the barriers between departments. In the end I was a little disappointed by this book. It gives some high level tools and techniques but it could be much more ...

In my opinion a change would be that someone from Operations will really participate within the project team and looks at it from an operation point of view. This way also these requirements will be taken into account and the system will be more easy to operate.
However there were also some interesting chapters so lets review.

Chapters

The book contains 7 chapters:

Evolution of a Software House

No pain, No gain

Plan of Attack

Tools and Technical Approaches

Culture and Behaviors

Hurdles to Look Out For

Measuring Success and Remaining Successful

Chapter 1 - Evolution of a Software House

As the name already suggests, this chapter is about the evolution of a software house. First it is a small company with no hierarchy and everybody knows each other. This makes communication easy and the releases of the software are coming fast. It is fun to work within such companies. But then it begins to grow and processes are needed. This is the beginning of a slow working company.

Chapter 2 - No pain, no gain

This is a chapter about organizational change. Investigate what is going wrong. It discusses some tools and techniques how to investigate the organization.
In my opinion not really about DevOps but more on change management.

Chapter 3 - Plan of Attack

This is again a change management chapter in which is explained how to communicate a new way of working. Setting the goal and visions and communicating this within your organization.

Chapter 4 - Tools and Technical approaches

This is an interesting chapter about the tools and techniques you can use to implement DevOps. To name a few:

Source control tools

Code reviews

Continuous Integration

Small increments

Test Driven Development

Automatic builds and testing

Architecturing the solution (loose coupling)

Provisioning

But then again these are just the tools and techniques development should already been using, when developing quality software.

Chapter 5 - Culture and Behaviors

This is a chapter about the soft side of DevOps. It discusses about:

Openness

Building trust

Collaboration

Rewarding good behavior

Transparency

Chapter 6 - Hurdles to Look Out For

A chapter about change management and about some theoretical change curve theory.

Chapter 7 - Measuring Success and Remaining Successful

This chapter discusses some tools to measure. To name a few:

Code Coverage

Code complexity

Commit rates

Unused Code

Coding rules

System monitoring

So also the things I would normally recommend.

Conclusions

The book was easy to read, but a lot about change management. Don't get me wrong, this is very important but there are other books about this subject. There were however some interesting chapters.

Some eye-openers within the book for me:

DevOps has impact on many departments: marketing, planning, development, operations, sales and HR.