Mario Mesaglio

Mario Mesaglio

Biography

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.

Contributions

rss  subscribe to this author

Bookmarks

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:

  • Did he know it was there?
  • Could he have used it?
  • Should he have used it?
  • Would he have used it?

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.

  • If team members do not know that reusable solutions have already been made, they will not use them.
  • If team members do not know where or how they can search for reusable solutions, they will not do so.
  • If team members cannot get a clear idea of the functional characteristics of a reusable solution, they will not know if it will satisfy current requirements.
  • If team members do not know how to use or access a reusable solution, they most certainly will not do so.
  • 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:

    1. Standardize functional and technical documentation templates and the place where they should be formally placed.
    2. Standardize the meta-data required to effectively discover and understand different types of existing solutions models.
    3. Establish an Enterprise Repository (or Service Registry or Catalog) able to upload the aforementioned meta-data and execute queries against it. Each record should give a link to its related standard documentation when needed.
    4. Establish a formal Discovery Process to search for existing solutions and to analyze its applicability within the analysis and design stages of a solution lifecycle, using the Enterprise Repository as the tool for doing so.

    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:

    • The definition of SLA Policies applied to each reusable solution – Without a clear SLA, it cannot be known whether or not a new consumer can add a certain amount of load to a particular reusable solution or if the solution can comply with consumer requirements. This is an over-simplification of the different implications of not having an SLA, but, in this case, we can determine that having them not only helps avoid unexpected behavior from the solution but also increases the confidence of every consumer that has access to it along its lifespan. This last statement strongly increases the odds of success of such initiatives, as it promotes additional political support towards its execution.
    • The strong Monitoring of each reusable solution load and performance in order to be able to act in a proactive manner towards the growth or modification of its underlying infrastructure if needed – This approach relates primarily with the aforementioned SLA, as they act as the core thresholds considered within this process. Additionally, the monitoring of a reusable solution gives constant feedback towards the vitality of its SLA in a way that verifies its validity and effectiveness along its lifespan and amongst different kinds of direct or contextual stress.
    • The effective application of Security Mechanisms to avoid unauthorized executions – Although this might seem like an expected approach towards any IT solution, especially the ones accessible to consumers residing on a different network level or even outside the company, it is important to allow the reuse of that solution only to authorized consumers. In this case, the authorization does entail the functional rights to do so and the reserved capacity of that solution for that single consumer. This last statement declares that this approach is not only a matter of technical consideration but of governance and management as well.
    • The definition of Reuse Policies to drive the analysis required to know if a certain consumer can make effective use of an existing reusable solution – This is not the same as the establishment of a formal discovery process, as explained in the previous question. Reuse policies take place once the reusable solution has been found and aim to balance the consumer's needs versus the solution capabilities and its SLAs. The application of these policies should establish an explicit contract between each part in case the needs balance correctly. Alternatively, the application should even determine that the consumer should not reuse that particular solution and should find another way to do whatever it was thought to be done with it.

    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.

    • The Governance should define policies and restrictions that enforce the discovery of existing solutions before the definition of new ones, such as: actors and roles specialized in supporting the execution of these policies; governance processes that aim to relate those roles and policies within pre-defined task flows and governance metrics to effectively estimate and/or measure re-use. The extent and scope that the governance would have regarding this matter depends entirely on the enterprise's governance scheme and cultural attributions.
    • The Methodology should add stages to IT Solution Lifecycle processes, on which to look after existing solutions that could be reused in each case. The place where these stages should be inserted within the Lifecycle may vary according to each enterprise methodology. However, as a common denominator, at least one of these stages should be inserted before Solution Design (technical, physical and logical) takes place and right after or within the functional analysis stages.
    • The Management should provide a means for auditing and executing the related processes, policies and restrictions defined by the governance and methodology, as well as defining a new process aimed to measure the effectiveness of them all. It is important to notice that "should" is not the same as "would", and with this kind of enforcement, strong political support is needed to drive its compliance.

    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:

    • Reduced freedom in analysis, design and development procedures – Analysts, architects and developers have less liberty in applying their own criteria on new requirements that may use existing reusable solutions, as, ideally, they do not need to work on them. This means less work, time and cost associated with that requirement, but, at the same time, many possibilities are being considered by them. Therefore, they might think they are being replaced, their jobs are being taken or their abilities are being underrated.
    • Reduced ownership and political power – This has to do with the internal social, economic and political structure of each company, as it relates to the human insecurity, professional hunger and search for power projected on those levels. As a department or business line, when you own and maintain a critical solution for a company, you automatically gain some treats that in one way or another affect these goals mostly in a positive manner. When an enterprise initiative drives reuse, which, in most cases, is a single part of a complex goal scheme, this threatens to take those treats away. Usually, a strong opposition is brought in place.

    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. 

    • A strong Educational Promotion and Knowledge Common Ground should be placed so as to increase the understanding of the technologies, methodologies, goals and considerations brought by the initiative. Knowledge common ground relates to the fact that many of these initiatives will require strong teamwork and effective communication, on which a knowledge common ground is needed to transmit and understand in the same way a single piece of information. A collateral but in no way less important effect of having strong educational promotion is the reduction of cultural resistance brought on by fear of the unknown and the misunderstanding of the consequences and their effects.
    • The promotion of Multidisciplinary Teamwork and Cross-Department Collaboration should be placed so as to reduce the logical distance between the different roles involved in the initiative, reducing bureaucracy, increasing trust between one another and overriding negative competition, though some healthy competition actually drives improvement. Note that bureaucracy is naturally generated because of the required collaboration, but it should be less complex or at least more effective than just leaving the collaboration without any proactive guidance or framework. The difficulty and effort required to make these steps effective depends on the organizational structure, governance, methodology, management, geographical distribution, communicational frameworks and maturity of each company. This has to be taken into account before expecting any kind of cultural resistance, as it gets very difficult to succeed once resentment, mistrust and other negative ideas take place amongst the different roles involved.

    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.

    Conclusion

    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.