Mario has worked since he was nineteen, and his first job was in a Telco SOA Software Factory. Two and a half years later, he climbed to a technical leadership position in the very same factory, and took charge of its management and methodology.
One year and a half later, he attained an SOA Consultant position and has been doing SOA-related consulting projects since, regarding subjects from SOA Enterprise Maturity, Architecture & Governance System Definition, to technical leadership and general service technology technical assistance.
Mario is currently working as the SOA Practice Lead and Consultant for Globallogic, with a total of six years of experience in the field. His main business-line specialization is in the Insurance domain, but he has also worked in Telco, Retail, Healthcare, and Public Services.
He's passionate about service-orientation, vendor-neutral architecture and design standard definition, and very fond of teaching. He has been coaching and preaching on service-oriented methodology for two years now, producing a lot of related material along the way.
Mario does not have a college degree, as he has applied himself 24/7 to his work since he started. Being an electronic technician and having studied two years of Electronic Engineering, he has been training himself in what is now his specialty: service-orientation, SOA, and Service Oriented Computing.
His main career goal is to help define new industry-wide SOA Design Patterns, best practices, standards, etc., and to become a main representative of the overall service-orientation methodology.
Know the Difference: Reusability vs. Reuse – Part II Published: December 31, 2015 • Service Technology Magazine Issue XCIII PDF
This is the second part of a two-part article series. The first part is published at Know the Difference: Reusability vs. Reuse – Part I.
From Reusability to Reuse
In this final chapter, some different approaches on how to promote reuse from a reusable solution will be presented. The scenarios taken as support for these approaches will be of the most generic nature, so to increase their applicability and understandability.
Take into consideration the following scenario:
John Doe is sitting in a room with a huge desk in front of him and a pen sitting on top. A second person comes into the room and asks John: "Can you sign me this document here?" John takes the pen, signs the document and hands the paper to them. One hour later, a third person asks for John to sign a different document. After revision, John complies.
John starts playing with the desk drawers and finds the personal seal given to him by his boss when he took the job so that he could sign corporative papers with ease. He smirks and leaves it visible on the desk.
With this in mind, a powerful question arises:
Why didn't John use the seal in the first place?
This, in turn, entails the following considerations:
All these considerations relate to the basic and fundamental steps to drive the actual reuse from reusable solutions, and they should be considered in the same order they were presented. Next, each of these considerations will be explained, adding reasons for its validity, examples, problems entailed by them. Finally, fundamental approaches to answering the problems will be proposed.
Did he know it was there?
"...He smirks and leaves it visible on the desk..."
Before arguing if it's good, bad, possible or impossible to use something, it must be determined if it exists, where and how to find it, what does it do and how it can be used, in that order.
This concept is broad in relation to the different measures needed to be taken to avoid its implications.
The most common and straightforward steps to resolving these issues are the following:
These steps will ensure the addition of a formal analysis on the existing solutions within IT project lifecycles, the standardization of information related to them and that the tools required to make an effective discovery process are put in place.
They do not need to rely on any specific product or vendor offering. The Enterprise Repository could be represented with a well-made spreadsheet or custom-made database, which is the most cost-effective in the majority of scenarios. It is important to correctly define the meta-data required to ease an effective discovery process, and manage the addition of that process within existing IT project lifecycles.
Could he have used it?
One of the most dangerous things to do within an initiative that strongly promotes reusability amongst its solutions (SOA initiatives, for example) is to disregard the fact that those solutions may not be prepared for the demand entailed and expected from them.
Although the aforementioned demand is considered positive (within such initiatives), meaning that those solutions have been found and were at least analyzed for reuse and re-composition (amongst other things), this does not ensure that they can constantly work as expected while being subjected to larger, different types of loads during their lifespans.
Several well-known approaches come to mind, including load balancing, infrastructure scalability and performance-driven quality. All of these are valid and positive towards this concept but are no different from the expectations of almost every IT solution, so they do not need to be explained in detail or closely related to this particular context.
Although many of the following approaches might seem to fit in the same category, they are mostly and irresponsibly ignored:
These four approaches determine that promoting reuse from a reusable solution is not just a matter of design, nor is it just a technical consideration. A reusable solution has its own vitality, as it exists as a continuously and collectively available IT resource that needs to be taken care of, measured, evolved and audited. Promoting reusability without taking care of what entails for it to work appropriately and consistently is irresponsible and counter-productive.
Many of the required skills to do so cannot be found on one particular Role. Better said, they should not be taken from one. This entails collaboration between multiple roles with solutions of these characteristics. The political power to enforce rules and procedures that aim to increase the compliance of these terms onto teams that make or use reusable solutions is also a core and fundamental requirement.
Should he have used it?
After all, it was "...given to him by his boss when he took the job so that he could..." use it. There is a strong concept there: "could." John did not have the moral, professional, technical or functional obligation to use the seal, so when he needed to execute the task for which the seal's original purpose was defined, he relied on the tools at hand.
This is one of the reasons that many reusable solutions may not be used by perfectly plausible and able consumers. They do not need to comply with any policy that aims to drive them to do so or restriction that would force them to at least justify another means.
On the other hand, if the customers do have policies and restrictions defined so that reusable solutions are used when they are compatible with new requirements at hand, they will have to look for existing solutions every time they need to design new solutions for them.
This pertains to all three fundamental components from which an enterprise can be divided: methodology, management and governance. If one of them fails to promote this, the effectiveness of its execution will be far from what is expected.
If the story had said "...given by his boss when he took the job in order to sign the papers with it," John probably would have searched for the seal when he needed to sign the papers.
All these approaches are heavily affected by the single most important problem found with this type of initiative: organizational cultural resistance. It increases the considerations and effort associated with every action taken to sustain the aforementioned promotions, enforcements and policies. This concept is further explained on the question "would," which is the last step for driving concrete reuse.
Would he have used it?
Why would John not use the seal if its predetermined and communicated purpose was to "...sign corporative papers with ease..."? Assuming that the three aforementioned considerations of it exists, can be used and should be used were all affirmative, what factors could still prevent a reusable solution to be reused?
This question pertains to the farthest from technical or architectural considerations the have regarding this matter; but one of the hardest to work on.
Free will is a matter of choice. John could choose not to use the seal, and there is no policy, restriction, process or tool that would be able to change that decision. It is a personal and sometimes passionate decision. This not only pertains to the context of this article but also to a constant in initiatives that changes enterprise methodology, management and/or governance: enterprise cultural resistance.
Promoting reusability does not only change the definition and design of a solution. When an initial investment is made so as to increase the reusability of a particular solution, the governance and ownership of that solution may be determined in a different fashion from traditional project-funded solutions. Note that this is not only regarding design-time. As mentioned, infrastructure, tools and collateral costs may be required.
A solution may not be considered to be completely owned and governed by the project and its managers that originally required it or even by the one who worked on its implementation. If the solution can be positioned as an enterprise solution, which is another strategy for increasing reusable potential, its funding, governance, management, maintenance and underlying infrastructure can all be given by a common or centralized-funding model, centralized or federated governance, middleware platforms and other resources that are owned by departments, business units or projects different from the ones that originally asked for them.
This last assertion justifies a large part of cultural resistance in the following ways:
There are many cultural aspects that must be taken into consideration within an enterprise initiative, and these are just the ones that mainly affect the reuse of already made reusable solutions. There are other considerations that affect how to drive reusability, which would have to be taken before, but they are not the focus of this article.
It is evident that there are non-technical factors that must be taken care of before and during the promotion of reusability and reuse. Some of them will be listed so as to provide a fundamental guide on how to treat these considerations.
The important thing to notice from any of them is the necessity of applying them before commencing the initiative or at least during its very beginning. These are the first considerations that should be brought to the table when considering the execution of an enterprise initiative that might bring cultural resistance, which might require the redistribution of ownership or require complex and larger cooperation and teamwork.
Moreover, the execution of preliminary processes like these can give a clear insight on how effectively the initiative would be executed at a certain point in time, as they could act as an assessment in order to decide whether to do it, wait, change its scope or terminate it.
The promotion of reusability within enterprise-wide initiatives is just one part of the whole framework of considerations that are required to perceive effective and constant reuse amongst initiatives that depend on it or aim to increase it, directly or collaterally.
Defining and implementing that framework is not a standardized "out-of-the-box" solution that can be immediately incorporated in a company or bought in like a product or tool. It entails a profound transformation that ranges from low-level technical factors to high-level political approaches that could and often do re-shape the structure of an enterprise.
Every part of that framework depends on the others, making the determination of relative effort invested on each a critical factor. This is why its misapplication is considered one of the main reasons for failure or false expectations generated by and related to such initiatives.
The effectiveness of defining this determination measures the maturity of the company in terms of "knowing itself." This means knowing its limitations, political characteristics, people, economic and funding models as well as how all of them relate to and depend on one another.
Not all companies have the level of maturity to be truly effective with initiatives of this kind, but that should not be taken as a final determination. If those initiatives have been applied for particular reasons, the enterprise should work on increasing its maturity to the point at which it feels confident enough to execute them successfully.
Then again, promoting reusability and reuse should not be considered an "all or nothing" concept. Taking care of the small things that make the required framework work, such as installing an enterprise registry and starting to change the way solutions are designed, helps increase the maturity of the enterprise and sharpen the tools that will be used once a full-blown initiative takes place.
Nevertheless, without the several considerations and concepts presented in this article and the ones that were not added for simplicity's sake, most enterprise will rely on those "small things" to attain a great part of the benefits expected from a complete reuse-driven or similar enterprise initiative, such as an SOA initiative. When those benefits are not delivered, the initiative that never formally existed fails before even starting.