Even Aces make mistakes: Reuse

Every year Debrah Lilley is kind enough to round up a couple of Oracle Aces to talk about projects, and/or new features at Oracle Open World.
This year we present a session with 9(!) people about our 'favorite' mistake we made and what we learned from it.

From the summary:

"A quick diversion from our now traditional featured short talks, this year our EMEA ACE Directors will share their biggest errors and what they learned from it. A fast, fun session that will energize you on your Oracle OpenWorld 2018 experience."

I have five minutes to talk about my favorite mistake, so this blog post elaborates on the topic a bit more.

Reuse

In software, we like to reuse code. This enhances productivity, it minimizes the chance of introducing new mistakes and gives us a chance to focus on the new things we are trying to accomplish, instead of reinventing the wheel. This has been a very strong driver of Service Oriented Architecture (SOA). 

There are multiple ways of implementing or realizing reuse:

• create a runtime component that you call from your code to do the job ('a service')
• create a library or code that you share from a central location and import in your code ('a common artifact in SOA Suite in MDS, or a library in Java or Node.js)
• a pattern ('template') that you apply as a best practice 
• a copy (!?) of the code you want to reuse and adapt. 

One of the downsides of reuse, is flexibility loss. If you are reusing something, a change to it will impact all the consumer or users of that piece of code. service etc. This is why micro services architecture is all about bounded contexts and decoupling using events. 

In SOA there has been a very common misconception: the fact that reuse is good, no matter what, resulting in inflexible very complex code that is expensive to change and, in the end, hard to reuse (!)

This particularly happens a lot with canonical models, and yes, I made that mistake too.

Let's go back in time, to a project where we created an application for the province of Overijssel for permits and grants, using Oracle SOA Suite 11g, a content management. The solution basically consisted of 4 different composites (Apply, Process, Decide, Notify), the Oracle Servicebus, a content management system, SAP ERP, a permit application and a.NET user interface.

For the integration between the .NET interface and the BPEL process support, we designed a canonical model.

Canonical model side note

The picture below shows what a canonical mode is supposed to do: make sure that in the servicebus and between applications, a canonical model is used.

End of side note

However, we decided to use the canonical model inside of our BPELs as well. This had several advantages:

1. we did not have to design the WSDL and XML Schemas for the BPEL
2. we could assign the entire message to the BPEL input and output variables

Change

We were done very fast, but we found we needed a number of changes in the canonical model to facilitate the .NET application. They wanted different structures and different fields. None of these had any functional impact on process flow, since the BPEL was mostly driving the process, adding approvals, enrichments and fetching and storing data in the correct backend system.
However, because we used the canonical model in all of our BPELs, we had to redo all of our assignments and xslts to pick up this new version, making sure nothing changed in the flow and functionality of the component.
The change cost the same amount of time as the inital realization, because the work in BPEL is not in clicking together the scopes, but in building the logic in the assignments and xslts.

Lessons learned

We learned a number of things from this particular approach:

1. Separation of concerns matters. This has been a long standing IT and computer science principle. See for example (https://en.wikipedia.org/wiki/Separation_of_concerns). There is a reason you put different groups in your electrical wiring in your house: if one of the groups fails, the other parts of the house are unaffected. When you have to make a change for a specific purpose, you should have to make that change in one place only. In case of the canonical model, in the servicebus and the components that are calling the servicebus.
2. Reuse has an impact on changeability and maintainability. To make sure things can be changed, apply the tolerant reader pattern ((https://martinfowler.com/bliki/TolerantReader.html)
3. Pick your reuse pattern carefully: a pattern you want to reuse (or a template), a library that you will apply, a service that you want to call, or creating a copy to be quick, but that you will be able to change independently.
4. Don't send data to systems that don't care about it. In this case were were sending data and dragging it along in the BPEL that were not needed in the BPEL. Typically all you need in the BPEL are identifiers and dates. Then, when you need more data in a specific scope, you can fetch it from the appropriate source. 

We refactored the code and made specific WSDLs and XSDs for all BPELs and used the canonical model in the OSB, where it belongs. 

It became a lot easier to work with the messages in the BPEL and changes in the UI had no or little impact on the process, as they should!

Code smells

So how do you know if you are reusing the canonical model too much. These are some tell tales that point in that direction:

SOA Suite

1. You have to redeploy 'MDS' everytime a new feature is defined
2. All your artefacts (WSDLs, XSDs, DVMs) are in MDS, there are no 'local composite' artefact
3. You have a lot of data in your messages in BPEL that are in none of the assigns or in only one of the assigns
4. You have a lot of merge conflicts with other teams that are working on completely different topics
5. You have a if statements in your BPEL that never merge back into 1 common flow, based on something in your canonical model

Java, Javascript

1. Your ORM library gets updated all the time and your code needs to change because of it.
2. You filter out values and fields in most of your code
3. You are extending the common objects to add your own behavior and attributes and filter out the common behavior. 

Conclusion

Reuse is a powerful and important topic to be productive and to avoid mistakes. However, reuse is not a goal, it is a means to an end.  Modern systems need to be changeable in the first place. Reuse should be carried out within the context as appropriate. Global models should be treated carefully and be minimized to where they add value and are needed. 

We can all learn from domain driven design principles and microservices architectures in our other architectures as well to make sure we don't paint ourselves into a corner!

Happy coding 😎

Mobile for business users

As I mentioned in a previous blog, Oracle Fusion Apps breaks with Oracle's past in the sense that the user interaction is built from a user perspective. Rather than exposing a datamodel or a business process to the user, they have designed the user interface based on information they have gathered about their user. Their website tells this compelling story, go check it out (after finishing this blog ;).

The world goes mobile

These days you can't just design for the desktop anymore. People use other devices like tablets and mobile phones and these devices are showing up in the workplace more and more. On top of that, people are working from different locations: from the office, from home, en route, or wherever they happen to be. This creates a new challenge when creating services or application. Take for example a HR self service application or an expense report application. Employees expect this functionality to be available everywhere, and on all devices.
At the other hand, organizations are struggling with the application of 'apps'. When I started programming, every piece of software had to have an API. Then the world realized that you want to integrate systems in heterogeneous landscapes and every piece of software needed to have a 'service interface'. Now that we have apps, every piece of software I realize needs to have a REST API so that people can create an app for that. The problem with this approach is that creating a service interface on every piece of software does not create a good service oriented architecture and creating a mobile interface for every piece of software does not create a good mobile user experience for your customers, employees and partners. So how should you approach this?

Oracle Fusion Applications User Experience Patterns and Guidelines 

The ADF User Experience patterns and guidelines site is a very good starting point for organizations that want to start using mobile for their applications. The site has four sections:

1. Design guidelines. This section explains that mobile design differs from designing for desktops. It  then states 10 mobile design guidelines. The most important ones are at the top: know your user and define the essential mobile task
2. Know your user is a separate section that talks about getting to know your user. You have to revisit your idea of your user and determine who will use your application on a mobile device and in what context this will happen. Creating personas is a very good technique that you can apply. The site has some references to this technique at the bottom. 
3. Create a mobile task flow. This section explains how your mobile tasks fit in the overall business process. Unfortunately this section is rather short and uses flow charting to show the flow in the user interface, and not the overall business process. It is very important that the business process and the (mobile) user interaction that is designed from the perspective of the user are aligned: otherwise you get into trouble with rules and regulations that exist in your organization for the business process that people are accessing using their mobile device.
4. Mobile design patterns. Users may not be used to using mobile applications for work, they use it at home and in their personal lives all the time. So using patterns that people are familiair with is important. You as a developer doesn't have to re-invent the wheel when creating the mobile tasks and your users are happy because the application works the way they expect. This will save money because there will less calls to the helpdesk, less errors and your application will actually be used ;)

OBUG Connect

Ultan Ó Broin and me will present some mobile design patterns that are defined in the process of designing mobile applications for Fusion apps at OBUG connect 2013, this afternoon. We will explain the importance of patterns and show some of the patterns that can be built with either ADF Mobile, or the native platform of a device.

Next: apply!

The next step is that projects start using these techniques to built user interaction for professional users, like we have been doing for consumer software for a long time. It is time that professionals get the user experience they deserve and need to be productive and happy while doing their job!