My team was technically strong, so they have decided that the testing strategy would include only automatic tests. The scope of the project was initially closed. So, the risk that tests would have to be reimplemented was low, because of the change requests. This was a good start.

To make the tests implementation faster, automatic tests were immediately developed for every component. By doing so, whether it was an API, screen, event consumer, bpm process, or other, the backlog item was instantly closed. How wonderful!

The team implemented more than 5000 automatic tests, correcting some issues. And we delivered the project to the client for the User Acceptance Testing. We were confident that this would be a success!

A few days’ time, we started getting not so good news… in fact, bad news. Some bugs were found, there were several unmet requirements, problems in processes that included more than one component, and some status machine had issues. Finally, some solutions met the requested requirements, but some requirements no longer made sense to the customer.

We were stunned; we had implemented automatic tests for all the components. Why had this strategy failed causing so many problems?

To answer that question, we needed to analyse the methodology used to manage the project scope and its deliveries. And the test strategy.

So, we went through all the requirements with the client. It looked like everything was perfect, but because we hadn’t done this in the first place, we caused ourselves some problems:

• Some requirements no longer made sense for the client when we implemented them. If we had reviewed them with the client, we would probably conclude that other requirements would make more sense, or the same ones but with some differences.
• How could some requirements not be being met, despite having implemented a solution for those requirements? Because in the beginning of the project we did not understand the real needs and pains of the client (we thought we had!). If the topics had been revisited during the project, we could have had a better understanding of their needs and more knowledge on their business. Continuous communication with the client allows us to understand their real pains.
• We developed the project using sprints, but we only delivered all features to the client in the end of project. Hence, we did not receive any feedback during all the development phase, and because of that we didn’t adjust the features to the client’s real requirements.

Automate didn’t kill manual tests.  

So, about the test strategy, we made a huge mistake: to believe that having almost 100% coverage of Automatic Unit Tests (functional tests) would result in almost zero bugs. We were so naive!

When we automate tests we need to ensure that the test is correctly implemented and really tests the requirement. When this is done by the person that develops the feature, then tests are influenced by this person’s knowledge about the implementation, and not by the requirements.

For example, if the developer misunderstood a business rule or implemented it wrongly, the test that he’ll implement will be according to his understanding, so it will be wrong and it won’t validate the business rule when executed.

If another person implements the test, they will look for the business rule specification and do the test without being influenced by its implementation.

If the test is not correctly implemented, this is not an issue because it will fail when executed. Someone will analyse the feature (and the test) and will fix the component with problems.

On the other hand, unit tests are not enough. Integration tests and system tests are essential to ensure that the system works holistically. Even so, testing each component singly with a 100% coverage, does not mean that the system has no bugs.

In fact, there are still bugs that can exist, like errors on the design or specification, incorrect assumptions about the meaning, units, or boundaries of the data being passed between, failures in message interpretation between systems, or other.

To mitigate this, every time an interaction between two components, systems, packages or microservices is developed, a set of integration tests must be executed. These tests are strong candidates to automation. 

Even when all integrations are working, the system testing must be executed because it “focuses on the behaviour and capabilities of a whole system or product”, validating that the system is complete and all processes work as expected.

For example, in a state machine implementation, sometimes some non-final statuses are forgotten and the transition event is not implemented. Other example is in event-driven systems, when sometimes an event is produced but no service consumes it and the process remains unfinished.

These kind of problems are usually found by executing system testing. These are the most important tests for any business, in my opinion. As ISTQB syllabus teaches us, testing includes checking whether the system meets specified requirements, but not only. It also involves validating whether the system will meet the client and its business needs in their operational environment(s). We need to understand if one process or functionality makes sense and works end-to-end.

What knowledge base to use? 

Automatic testing is a strong testing tool, but it cannot replace all manual tests. We need to evaluate the whole system characteristics and environment to understand what tests we should execute manually, and what tests we should automate.

To decide the test strategy it’s important to understand the advantages and disadvantages of each approach.

Manual testing is a knowledge science activity that includes human judgment and capacity to analyse if something makes sense. If we do not execute manual testing, we lose the advantage of experience-based test techniques, and the human capacity to analyse if the solution makes sense for the business and meets the requirements.

Manual testing give us a chance to find extra bugs that automated tests would never find, because it allows us to follow that gut feeling that “something smells bad” and explore themes that may not have been tested or required.

Even when we decide to implement automated testing, we should test the software manually before running the automated tests. First, to be sure that automation is possible, and then to ensure that this automation is correct.

Automated testing is an exact science that ensures accurate results. It is software testing other software.

Testing a new feature manually could be fun, but testing the same features time and time again to prevent regression issues can be demotivating, leading to frustration and wasting time. That is why regression tests automation is a very important mechanism to save money and spare the test team.

And how about performance and load tests? It is insane to execute those tests manually! You could try but you’ll take a lifetime, and probably the tests won´t be accurate and the test coverage will be smaller. The greater the software and the more stable the feature scope, the greater value of testing automation.

When a part of the testing process is automated, you have many advantages:

• The productivity increases because the test execution is faster.
• Your confidence grows since you’re more reliable and error proofing.
• Your team is more efficient because the tests after implementation are repeatable without human intervention, and the team can use their energy on non-automated tasks.

Check the following table to see when each test is more suitable:

Bet your money on the right testing.

So, the one-million-dollar answer to the question on how 5000 automated tests were made and the project failed is simple: the test strategy was wrong!

We need to find the right balance between automated and manual testing, because each one has strengths and weaknesses. Their value only exists when they are applied in the right environment.

As an agile company, Polarising implements automated tests to save teams, time, and above all, to deliver high-quality software. However, to ensure that the solutions bring value and are the right ones to your business requirements, manual tests are also performed.

Márcia Catarino
Business Analyst

Links
https://www.testim.io/blog/test-automation-vs-manual-testing/
https://www.guru99.com/difference-automated-vs-manual-testing.html
https://www.testingcompany.com.br/blog/teste-manual-de-software/
http://www.tecnisys.com.br/noticias/2019/teste-manual-vs-teste-automatizado
https://www.softwaretestingmaterial.com/automation-testing-vs-manual-testing/

To be agile you must focus on several elements such as the continuous value of your product, the constant adaptability to changes in the requirements, the capability of delivery on a short term, the interaction between all the project actors, the end-users and the self-management competence of the teams, among others.

Well, now you kind of know what is to be agile… but do you know how to make sure that you are really doing it?

And please, don’t answer that you “just know” because you feel you are a “flexible and fast thinker” … This is not a job interview, and believe me, when you need to justify to the company board why Agile is the way to go you will need data, numbers, facts! Because information is power.

Be multidimensionally agile.

First you need to know what to measure exactly, and for that you must understand for which dimensions the Agile methodology looks for in a company and how those dimensions are impacted and, subsequently, how to evaluate or measure them.

There are four dimensions impacted by Agile and each one of these dimensions will be the platform to check different pulses:

Let’s start with Business. Here you will measure effectiveness by assessing how your delivery is reaching the goal. We could make a giant list of agile metrics, but let’s keep it simple!

Choose a major question instead: Are you solving the business needs? The Fitness For Purpose Score is a good way to check that. You must understand the customer’s purpose for consuming what you’re offering. Then, you can create the appropriate fitness criteria metrics. You can set this score, considering: Net Fitness Score [NFS] = % satisfied customers – % dissatisfied customers

Another valuable metrics for effectiveness are the Pirate Metrics: acquisition, activation, retention, referral, and revenue. Maybe you will encounter some products where some of these indicators won’t fit, just apply the ones that do. Check this cool illustration to help you understand these 5 steps really quick:

Image: Startup Metrics for Pirates by Dave McClure

Let’s now travel to the next dimension: Organizational, where you will measure efficiency. This is the moment to put your team under the microscope and evaluate their overall performance.

One of the most important agile metrics that will help you do this is the Lead Time: how long are you taking from “To Do” to “Done”? This is one of the easiest, simplest, and accurate metrics you can use, especially when you are supporting your tasks management with Kanban methodology:

Image: Kanban Board

You can apply the metric to the total time from the point of agreement to the point of delivery and/or to how long the tasks/features last in each phase. It’s also important to verify the Waiting Time (how long an item continues between the conclusion of one phase to the next one).

You should associate the Lead Time with others like, WIP (Work in Progress) and Throughput. The WIP considers what is “Ongoing” but also the tasks from “To Do” to “Done”. By attending to this you will help your team to focus on finishing the tasks already started before starting new ones.

The Throughput will tell you the average work units per time units. It will help you, for instance, to know how many items your team can deliver in a week and if that number is increasing or decreasing through the life cycle of the project (so you can identify either possible blockers and facilitators of their workflow).

Image: The Lead Time is improved by shrinking the WIP

Let’s now check the Technical dimension to see the excellency of your work. Meaning: does your team works fast, but has the result real quality?

The measures you use here are known and not exclusive of Agile: how many bugs do you have? How much of the product do your tests cover? And what about the infrastructure? Is it robust enough to support your product? Does your code have 15.000 lines that you just realized that aren’t used for anything?

If you work for an IT company and still need explanation on how to measure this, maybe you should rethink your career … just kidding! (no… for real, question yourself!)

For last, but not (at all) the least, we imperatively must look at the Cultural dimension to check the ecosystem. To be agile your organizational culture must be agile. There is no way to jump this step.

How happy is your team, the organization in general, the project participants? Is it even possible to measure emotions? Oh yeah! For instance, through Burnout Tests or the Happiness Radar, using just a simple white board where your team members can mark the areas they’re happy, neutral or unhappy about. Ok, it’s a little corny, but I’ll take my chances… just feel your team’s heart!

Image: Hapiness Radar

Don’t be just any agile-cherry on top.

As you can see you have many metrics to check up your agility (and we are just giving you a few examples), so please don’t go crazy and megalomaniac and start applying every metric you know every step of the way!

Last piece of advice, simply follow these two rules:

1 – Be aware of toxic metrics: don’t start measuring a team member or comparing teams. This will only undermine your environment. Promote collaboration, not competition.

2 – Take it easy, understand which metrics make more sense to your team/project/product and start your own agility barometer!

Now, you are ready to go.

Dulce Monteiro
Polarising Business Analyst

Contact Polarising for tech that works: info@polarising.com

The market is competitive but there are some more “resilient” collaboration tools than others. In 2005 Linus Torvalds presented to the world a new distributive source-control management (SCM), which he named git. A few years later it has become the most adopted SCM in the world, dethroning some of the most popular ones, such as SVN or CVS.

Nowadays, git is primary a hosting provider for large companies like Microsoft, GitHub, Gitlab, Bitbucket and it is used by millions of users every minute. This video series from Scott Hanselman is very complete, if you have a chance, watch it.

There are tools and Git Workflows.

There are several collaboration strategies; from the simplest one where every member of the team commits to the same branch, to a more structured workflow approach, such as the notorious Gitflow.

Most community collaboration projects follow a Fork and Pull Request (PR): the user creates a copy of the project to themselves, implementing the fix or adding a feature, to finally create a PR to the origin repository that the owner(s) can accept, request changes or reject.

But the GitLab flow and the GitHub flow are both intended to simplify the workflow, making it more “agile” in continuous deployment models. Atlassian has a nice article comparing several models, including the Centralized Workflow, Feature Branch Workflow and the Forking Workflow.

Go with the Gitflow.

The Gitflow workflow model was proposed by Vincent Driessen in 2010 and ten years later it is one of the most used models by development teams. Its core resides on multiple branches with suggestive naming and semantic meaning.

Image from nvie.com 

Main and Supporting Branches.

There are two main branches In Gitflow: master and develop. The master branch is considered when the code is ready-to-go to production and it’s the root of all truth.  As to the develop branch, it is considered as the current state of the project development.

When the release management establishes that development is finished or the developed features are Done (i.e. respects the project definition of done, passes the tests, etc), a new Release should be made by merging the code from the develop branch into the release branch, do some maintenance task and then merge into master branch, usually through a pull request.

There are three more supporting branches from the original model, like Feature branches, Release branches and Hotfix branches:

Feature branches are the ones that reflect the application development features, like bug fixes or project work items, that will not break the application day to day activities.  If it is something with serious impact on production, you should consider using the Hotfix branches. Once the feature is done the code is merged into the develop branch through a pull request and all remaining feature branches should sync with it to import the latest changes.

Released branches are created from the develop branch and reflect a new release version to be prepared. Within this branch, several activities like bumping the release version are in order. Once the release is closed and considered done, the code is merged into the master branch as this version is on production environment.

Finally, the Hotfix branches is where critical application errors or bugs are going to be fixed. Once implemented the are merged into the master branch so they can be deployed into production environment and then into the develop branch, so the fix would be integrated into all in progress developments.

Vincent Driessen also makes available in his GitHub repository a collection of git extensions to provide repository actions to relate to Gitflow mode.

Why using a Collaborative Model?

Choosing your team collaborative model should be a thoughtful decision that needs to also consider the release management model. But most important, this model must adapt to the project needs, always having in mind that there is no such thing as a model that fits all.

A structured and defined released model makes any collaboration model simpler, turning CI/CD pipelines more effective. The more chaotic the release model you select, the more complex it will be the collaboration flow model, and in these cases I recommend an extra branch called prerelease branches.

These prerelease branches are created from develop branches and merged from feature branches as pull requests. This way you can combine features into new branches to be “deployed” and “tested” in user acceptance test environments, validating any feature that may not be approved right away.

If you’re are still in doubt about the best Collaboration model for your project, I hope this article brings some clarity: the Gitflow model can be adapted to your’s and your team’s more complex needs, having some automations that can be made like automatic semantic versioning through gitversion or through git TAGs.

Nuno Cancelo
Polarising Consultant

References: https://git-scm.com
https://www.toptal.com/git/git-workflows-for-pros-a-good-git-guide
https://nvie.com/posts/a-successful-git-branching-model/

We already read about the benefits of remote work, they are undeniable; at Polarising is not new to anyone, as we have the flexibility to do it when we feel it will improve our performance.

But if there has been a general underestimated idea of this context, now we know how equally important both office and remote work are to that work-life balance companies and employees are always advocating.

So, Polarising decided to re-open the office in that assumption: just because things cannot be as they were, it does not necessarily mean we have to exclude any of the options!

República’s office is open since June 1st with limited capacity, and for that we had to come up with a solution that allows anyone to see if there’s place available to go and take care of business or just have a relaxing day outside home.

The challenge.

HR, LABS and Communication teams were already working together to prepare everything, and there were some ideas and possibilities on the table. Finally, I was contacted and asked to develop a registration app. There was a catch, thou… I had two days to do it!

This app had to be a quick and effective solution that allowed each one of our employees to book their day/ place and parking space in the office building.

A few months ago, I had decided to learn a little about Microsoft power apps, an Office 365 tool in which we all have a Polarising account. The concept is to develop no-code applications for PC, Tablet or Mobile. The data sources of these applications can be simple excel files, sharepoint or database repositories.

Another advantage is that it’s very easy to publish applications that can be used, for example, by integrating or embedding them in a website or in Microsoft Teams.

The requirements.

This app had to have some specific requirements, of course:

• an app that any and only Polarising employees can access
• a feature that allows to schedule the days at the office in each of the 3 floors and manage the number of people registered on each floor
• when seats run out on a floor, no more bookings can be made for that floor on that day
• it is possible for each employee to make only one reservation per day and to unbook a reservation
• a feature that allows to book and unbook a specific parking space and only one space reservation per day
• it is possible to check Booking and Parking Space details of all registered employees at any time
• booking history must be saved.

The solution.

After comprehending what was needed, I went to work! My biggest challenges were fields like Data and Calendar, as well as using the logged user information in to the App, so I could make the reservation on it behalf, two concepts that I hadn’t yet used working with power apps; and it wasn’t as easy as I thought!

Step by step and overcoming each challenge, I came up with a first draft version of the app; I was ready to run some tests, so I asked the team to do it covering all sorts of possible scenarios, and most important, to suggest improvements if necessary.

The tests went so smoothly and mission accomplished: Polarising has an “express-app” ready to welcome all on June 1st, according to all safety procedures!

Working as a team was fundamental to have this application ready and functional on time.

It’s great to be back!

Márcia Catarino
Business Analyst

Everything can go wrong! The product could be so complex that your clients cannot use it, making impossible to meet the sales goal. So, is there any way to prevent such problems? How to reduce the risk of failure and guarantee your product meets the client requirements?

If you are a product owner or a product marketeer, you must know that it’s imperative to speak to your customer, so you know what to build or if what you are creating is, in fact, what they need. This is called Product discovery, where you get data from your client in order to guarantee that you’re working on the right solution to address the problem they are experiencing every day.

Often, we have the preconceived idea about what can be the best solution but when it hits the market, the acceptance rate is so low that sales are even worse than predicted. It’s easier, cheaper and less time consuming to change something that is still in the initial phase, so you should be sure about what you want to build.

There is no blueprint on how to do a product discovery. The main objective of these phase is to get more knowledge over time, so you can understand better what is the best solution to invest in. A good approach can be summarized by these three activities:

• Interviews: talk with your target and\or investors. Understand what their problems are and get feedback on proof of concepts, prototypes or minimal viable products.
• Prototypes or proof of concept: get basic examples of the functionalities that work; they might not be integrated or even fully working but they will allow you to have a better understanding of the product and get feedback before spending time on developing and refining the product;
• Minimal viable product: have an MVP release with a basic infrastructure to have everything prepared like in the production phase and customers can test your product and give feedback on the released features.

These are basic activities that can be used with any product; you can always add more or choose the ones that better serve you project, as long as these activities help you learn something about your customer by getting information and feedback.

Product discovery is not something that you do only when starting a project, but something you should do as much as possible. Every time you talk to your customer more problems, ideas and solutions will appear. And every time all need to be validated and converted into future features of the product.

However, during the Product discovery phase you can face some problems that can be easily identified, such as:

Not being able to embrace the discovery mentality. You do not need to make complex questions to have an idea, either of the problem or the product itself. Just be smart; people with a discovery mentality will not settle for the first idea or make pre-assumptions. Do more questions and test the ones that matter, be curious about the context of the product, and more important, have an open mind.

Not concluding the discovery cycle. You got all the relevant information from your clients, tested the possible solutions, gathered a team to design and build the product, and finally it was tested and approved; well done! But it’s not yet time to start the next project because, in reality, your work is just starting. After the product launch you need to setup solid milestones to evaluate the product success, as well as create and\or adapt the channels from where you collected feedback on the latest changes, and inject that information back to the discovery cycle to help you make future decisions.

Do it yourself, not a third party. The main purpose of a product discovery is for you to learn as much and as fast as you can about your client problems. If you get a third party to do that work, you will never learn it just be reading interviews and reports; same will apply to a department in you company. Don’t be afraid to get your hands dirty and take an active role in the process, innovation emerges from collaboration!

Your team should be multi-disciplinary. Product discovery requires many skills like design, marketing, development, just to name a few, which means that you should assemble a multi-disciplinary team that aggregates everyone that is involved in developing the product. Usually what happens is having many intervenient in the process, making it prone to consume unnecessary time and resources.

Ideas or features coming from other people besides the client. Many companies work based on everyone’s ideas about the client or on market knowledge, but there’s only way of knowing what your client wants and that is talking to them and see what problems are worth to pursue.

So now you know what it takes to build a strategy based in Product Discovery. But use it wisely to create and not to validate an existing solution, this is a waste of money and it will only bring new problems. Keep in mind that the discovery phase is a continuous process that will allow you to learn more about your client over time, focusing on building what adds value to them and finding the right market positioning.

Tiago Simões
Polarising Consultant

What most stands out to me is “high-level visual summary” because over time there are changes in any product roadmap. For a start-up or a product in its embryonic state, this is very important. In fact, if the roadmap does not change it’s because something is wrong! So do not panic if this happens every week or month, it’s normal, in fact, it shows you are on the right track to respond to customer’s needs. Also, changing the product roadmap can mean that you are keeping up with the latest technology developments and this can only favour your product or business.

General Picture.
The only part of a roadmap that needs to be clear and sort of fixed, is its final goal and the overall vision for the product. Some good questions to ask yourself are:

• What are the required features the product needs to provide real value to the customer?
• What are the “nice to have” features that can be implemented in the future?
• Where will the product be 5 years from now?

When building new products, it’s good to think of the 80/20 pareto principle that defends the delivery of 80% of the product value with 20% of its features. Applying this rule can help answering all other questions.

An additional tip on how to define a clear product vision can be found also at Product Talk, just by following the link: https://www.producttalk.org/vision/. Also, if you share the roadmap and product vision with your customers and stakeholders, they will feel engaged and contribute to its evolution in time, maintaining their interest and investment from the MVP to the beta version.

It takes organization.
A good product roadmap takes time and planning. Make sure you organise and produce clear technical documentation explaining all stages and every final decision. It can be a small chapter together with the documentation or just an appendix. Starting with this kind of organization will pay off later since every step can be traced, as well as keeping future iterations aligned with the overall objectives.

Tiago Simões
Polarising Consultant

Recruitment is key to IT companies like Polarising: for the past year, we have been working on a decision-support tool that will revolutionize the way these companies evaluate incoming candidates, and it has been very challenging and rewarding! By studying the integration of machine learning techniques in Polarising’s recruitment process, results are very promising.

I’m sure you’re familiar with the term but in case you’re wondering, machine learning is an application of artificial intelligence (AI) that provides systems the ability to automatically learn and improve from experience without being explicitly programmed.

The core idea of this tool is very simple; to process each collaborator cv in order to understand their overall attributes, a list of similar collaborators, open position rankings and group classification. The overall attributes represent candidate’s main characteristics, which will be verified against the list of similar collaborators resembling the evaluated candidate. As to the rankings, they analyse how adequate a candidate is for a certain job position and finally, the group classification represents the group to which the candidate is more adequate, based on his/her characteristics.

From a recruiter’s perspective, instead of analyzing the candidate just by its cv and make a decision based only on his/her understanding, extra and valuable information will be available in order to form a solid opinion and support the decision process of choosing the best candidate. With this tool, the recruiter just needs to fill the candidate’s technical skills and work experience in the system’s web application, instantly receiving a set of outputs generated by the system itself.

This said, it’s obvious for Polarising that our Recruitment process will benefit from machine learning, as it improves its efficiency. Performing a more deterministic procedure and finding structure and patterns in data, is the dream of any good recruiter in this area and we only go for the best! I hope this brief article can transmit the potential of machine learning to maximize your company’s processes too, it has certainly challenged me and my team.

Henrique Delgado
Polarising Consultant

Well, of course this is wishful thinking, since most projects are not that perfect and you don’t control every aspect of it. On the other hand, their complexity requires multiple tasks to deliver.

So, try to imagine a one year project developed with agile methodologies, with deliveries every two weeks (26 to be precise), and on top of that, several components that need to be reviewed and prepared carefully.  If it’s a small team it can be even more complicated, consuming resources that can be used to work on release features or to ensure the code quality.

At Polarising we use two tools to complete these tasks: Jenkins and SonarQube. To better contextualize, here’s a brief description of what consists each tool:

Jenkins is used to automate all sorts of tasks related to building, testing, delivering and deploying software. It can have different environments for each configuration, like Java, Python, Angular, etc. SonarQube is a tool used to maintain the quality of the code, like bugs, tests coverage, unused code, etc.

Every time there is a commit of new code to the source repository, a “wake up” Jenkins web hook goes off. In an earlier stage, Jenkins will download the new code, install everything that it needs and starts to run unit tests to check if everything is working properly.

After all the tests were done with flying colors, SonarQube will proceed to its quality analysis, generating a full report on the quality of the code created, based in the acceptance criteria of the quality these phase can have an error or not.

The final stage of deployment is only executed if the code is from the main branch of development or delivery, and the code will be compiled and created a deployed of the same. If it is a mobile app it can be uploaded for Google Play or to the Apple Store. If the code is from a server it will be compiled into a docker image and published into a registry that will allow an easier update or system deployment.

If in any of these stages occurs an error, the process is stopped and an email alert is sent to the development team. This flow is just one of the possibilities, since there are other kinds of automation. Jenkins is a simple tool that has several plugins and many configurations that can simplify a Developer’s life.

If you are like me, you’ll prefer to spend time developing rather than deploying. Besides being boring, you can miss something you’ll possibly need further and have to redo everything: what a pain! With Jenkins you only have to do some configurations and have a file that will say what needs to be done, setting you free for other tasks like making sure everything will run perfectly and you do a job well done!

Tiago Simões
Polarising Consultant

Is there a right and wrong approach for a specific type of business? First, let’s check each one out.

Point-to-point Architecture
Already in the category of legacy architecture, this was the most common architecture in the early 2000’s. It consisted in the integration of data from several applications, using a specific channel for each integration flow. This means an ever-growing number of channels and connections between systems, making it difficult to manage the Integration Platform.

Simple to design and implement, this type of middleware might be a good option for low scale integration scenarios where change is predictable. Otherwise, it’s not a recommend architecture, since it has high maintenance costs per each application added, leading to the redevelopment of each connector to each application. It was this lack of scalability that led to what it’s usually referred as a “spaghetti” architecture.

SOA (Service Oriented Architecture)
To face the challenge of scalability, SOA emerged as an approach that allowed to decouple all integrated applications by exposing their functionalities as services. Each service can then be used as a small building block to compose larger functionalities and systems, leveraging on a centralised Enterprise Service Bus and standardised messaging. This aims to ensure high service reuse, with easier governance and change management, since changes can be performed only on ESB-level and abstracted from other systems.

This type of architecture has become mainstream for the last 15 to 20 years in what concerns to integration and has allowed several companies to easily integrate their systems and those of external partners. But on its downside, SOA has proven itself hard to govern in not so controlled environments, creating similar services and wasting its reuse potential.

Governance requires the definition and enforcement of a strict set of rules, usually by an Architecture team or a SOA Centre of Excellence. This is something that most companies wrongly see as an avoidable cost, leading to an ungoverned SOA that can easily be also compared with a “spaghetti” architecture.

Microservices Architecture
This “newcomer” shares several characteristics with a SOA architecture, aiming to achieve some of its goals. And it does so with the promise of a simpler architecture, easier to govern, more scalable and better suited to the advent of cloud computing.

How? Well, it’s precisely here that you can find the difference between a SOA service and a Microservice. Where in SOA, services are seen as mere building blocks of one large platform/framework that can be used to orchestrate larger functionalities and processes, Microservices are completely independent entities that can evolve on different lifecycles and be developed in different technologies, also following a different sets of rules, scaled as needed, without impacting each other.

While this leads to a more flexible architecture that can easily scale and adapt to a company’s evolving needs, there is a growing risk of losing control of microservices and ending up with a set of unmanageable services, again resembling a “spaghetti” architecture – where have we heard this already?!

A few more architectures or variations could be named, such as an Event-Driven Architecture (EDA) or a Database-oriented Middleware (for which Polarising developed PortaTM, a Java-based software that allows the exposure of Stored Procedures as Webservices).

In the end, the often-unanswered question is what’s the best architecture. From my experience it all resumes to determine the best approach for each scenario. Although being the “next best thing”, a Microservices architecture is far from being ideal to every business. SOA is a proven architecture, suitable for most scenarios but it requires strong governance to evolve properly. And even a point-to-point architecture can be suitable in some small-scale scenarios, even though it has fallen in disuse.

It’s clear to me that only with experience are we able to access such scenarios and determine the best option. One should always investigate past projects for lessons learned, understand what best fits the next project/challenge and avoid following the “new buzz” just for the sake of being the latest trend. I could name a few companies that are always implementing the “next best thing” and end up with a large set of legacy integration platforms and a nightmare to manage in the future… But I won’t;-)

Hugo Pascoalinho
Polarising Consultant

Here at Polarising, we strive to provide the skills and options that are better suited for each of our customers businesses. We know that some methodologies are more advantageous for small companies and others will hold better when there are massive scale or very complex data transactions.

But there are programming platforms that can be used to build pretty much any kind of software application and serve a wide array of business needs, from CRM to finance to supply management and redesign them as needed. That’s what .NET does, and we’re seeing how versatile it is first hand.

As of right now, two .NET programming languages, Visual Basic .NET and C#, are among the six most widely used programming languages for software development around the world, according to the May 2019 Tiobe Index. There are a few core characteristics that explain why: it allows the use of multiple languages, has super easy integration with Windows and Microsoft products (they built it, after all), offers horizontal scalability and consistent UI practices, and because the ecosystem is so large and powerful, all the tools have been pre-tested and can be easily accessed.

First launched in 2002, the .NET Framework is now in generation 4.8, the latest version freshly released and with several enhancements in critical areas, most notably security patches, bug fixes, and product improvements. But more trendy now is .NET Core, a more recent development aimed at simplifying development and testing with a free, open source, cross-platform solution.

This is a redesigned version of the .NET Framework that allows the deployment of apps in multiple environments, from mobile to desktop to cloud, and for Windows, MacOS, and Linux. It’s yet another useful tool to have in your skillset, as a specialist in this area, especially as it grows and develops. Core is potentially revolutionary and we want to be a part of that future.

Growth trajectory
The community of .NET developers is growing and Polarising, as one of Portugal’s Best Companies to Work, is part of that. We’ve got specialized teams working with these frameworks, which is another tool in our toolbox of software engineering, alongside a team of 60+ professionals dedicated to the Spring Framework, for instance. We belive that investing in this technology is to assure a wider know-how that allows any programmer to open doors into new career opportunities, providing our customers the best solutions.

These are skills for the now and for the future, as is superbly known at a time when demand for IT professionals with programming skills is at an all-time high, and both Europe and the U.S. show signs of an increasing skills shortage. Speaking of which, a recent study published by consultancy firm EY Global recognizes the problem and stresses that the most digitally mature companies tend to have higher productivity and lower staff turnover. It’s a good outlook to have when planning for the next five years, right?