Sebastian Gnagnarella

Lot of things, but deep inside just a Geek,,, well not so deep…

Continuos Integration as a Martial Art

Few months ago I read a great article that was suggesting a journey for CI comparing it with the different steps in learning Karate.

Unfortunately the article was in Spanish so I couldn’t share it right away, but I decided to take some minutes this morning and come up with a rough translation for y’all.

Original Article from Martin Salias:

* In case you are a Karate guru on the team ,  the belt colors may be out of order or just wrong 🙂 *

White Belt

  • Install Team City or Jenkins
  • Every team should learn how to configure their own projects
  • Each commit has to automatically compile
  • Projects in RED are not allowed

Yellow Belt

  • Start with tests and run them with every commit
  • Again, projects in RED are not allowed, use this opportunity to learn what the others are doing and stabilize the tests

Orange Belt

  • Start with TDD and ATDD, increase the number of tests too
  • Start measuring code coverage and enforcing it (at least 1% for each new class)
  • Start increasing the code coverage limit, if the code coverage is not satisfied the project should go in RED
  • Every time a bug is reported in test or prod, write the test to demonstrate the issue first, and then fix it

Green Belt

  • Start executing static code analyzer and have the build server reporting on them
  • Focus on the main issues reported, and once fixed, start enforcing code quality (project goes into RED if it is not passing)

Blue Belt

  • Start versioning code together with database migrations, configurations and libraries
  • Make the build server compile, run all the tests and validations and generate a new testing environment from scratch

Brown Belt

  • Work with dev ops and web ops to validate and adopt environment deployment scripts and processes
  • Have the build server create a test environment from scratch with every commit and also an incremental one (upgrade/update)
  • Automatic rollbacks in the incremental environment using scripts

Red Belt

  • Every time there is a commit and all tests and validations pass, generate a package that can be deployed to production with the click of a button.
  • Start working on hot-deploy , non user impacting , deployment automation

Black Belt

  • Every time there is a commit, goes to production without interrupting the service

Does the CIO make that call or do the architects make the decision with the CIO’s input?

Few weeks ago, a good college of mine asked for my opinion on this matter. I’ve realized I haven’t written anything in a while, and you know… :).

Here is my answer :

In my mind one of the CIO’s responsibilities is to define the high level technology strategy and although he/she may not be fully equipped to decide on a particular technology stack – lack of domain knowledge or just not enough time to research all the options available – she should collaborate with the architects and feel confortable with the decision (also stand behind it as there is no room for pointing fingers later!).

There are plenty of consideration when settling on a technology stack that may not be part of the architect purview:

  • Technology Market Adoption
  • Potential developers available in the market
  • Company long term road map and strategy
  • Financial factors
  • Future strategic alliances

Also there are plenty of considerations that may escape the CIO’s knowledge:

  • Frameworks available
  • Technology Performance for a certain task
  • etc


It is also the CIO’s job to help the team broaden their spectrum and “force” them to do research. Let’s say you are working with a Java architect – although I rather architects to be technology agnostic – if that person is reluctant to using other technologies, he will try to solve the problem with Java (you know, if the only tool you know is a hammer….).

Summing up, the CIO/CTO should define the global strategy considering technology and non-technology factors and foster internal research. Architects should come back with a variety of options and healthy debate should happen. The CIO will be ultimately responsible for the decision in front of the executive team and the board. This is a really important choice to be taken by just one person, and for some reason you have hired architects.

Some Thoughts on Product Development

This blog is based on my participation in a panel during the Denver Startup week on 10/1 at Spiredigital.

Thank to Nick Coppolo for putting the questionnaire together.

What’s your view of product development and how does that guide what you do each day?
I could give the PMBOK definition, but, no,,,, for me Product Development is the art and process of marrying customer/business needs with technology solutions.

In my experience I’ve seen 3 challenges with this :

  • Customer needs are different from what they tell you they need.
  • Sometimes customers do not know what they need and requiere an expert advice (as Henry Ford said “… If I had asked people what they wanted, they would have said faster horses…”.
  • (We) Technologists like to build cool Shi*, that may not have anything to do with business needs or could include a lot of gold-plating.

To avoid all of this I usually recommend a lean development approach, short iterations and a lot of prototype development (when possible) – allow you customers to experience often and provide feedback.

What were some initial challenges you face in receiving approval or proving a market fit for your product, prior to beginning development?
This varies from project to project but everything usually boils to $$$, the easiest path to receive approval is to compare investment with ROI.

Did you often have to pivot throughout the ideation and development process, and why? Was it for the better or worse?
Pivoting throughout ideation and development is a key part of agile development, however I like to have a clear picture of the end result before starting. The worst thing we can do to a development team is to switch gears in the middle of a project and start building something completely different. On the other hand, fine tuning is expected and should be welcome.

What does your product development team look like?
This also varies from project to project. Ideally we have a project manager, a BA, a product manager (the liaison between the business and the tech team), a testing team and a development team. If the project is developed using a partner or an agency, we usually try to match up their resources with few internal resources (which I name “champions”). I.e. have an in-house product manager working with their product manager and BA, an in-house developer working with their development team, etc – this practice helps to keep key knowledge in house and drive the use best practices.

What’s your view on outsourcing or using outside resources to develop your product?
Related to this question I distinguish two types of outsourcing: by project and staff augmentation. The earlier implies that the vendor/partner/agency provides a full project team and sometimes own processes (that I rather complement with internal resources as I said before), the later means just an addition of developers to augment delivery.
In both scenarios it is just a matter of finding a partner that clicks with the company culture and the internal team. Sometimes that click will be driven by really subjective things (I “like” their developers), sometimes will be driven by objective things (we can only work with local/on-site resources) and sometimes a combination of both – the key is to find what works for your team and company and find “partners” not simple “vendors“.

What are the keys to shipping product to market quickly and successfully?
The main challenge is to go from 0 to 1 and come with that MVP. Projects get delayed a day at a time and frameworks like scrum help to mitigate or prevent this.

What advice would you give people in the beginning stages of developing or ideating their product?

  • Have a clear vision for your “forest” and start planting “tree by tree”.
  • Spend good time in ideation and architecture, but do not over spend. Build a bazaar not a cathedral.
  • Adopt agile methodologies.
  • Build you architecture to scale (do not underestimate your possible success), this applies to both hardware and software.
  • Decouple your architecture as much as possible, this will allow you to distribute and parallelize work.
  • Create prototypes and get user feedback soon, do not ideate in a vacuum.


This is the second post of a series based on a talk I gave at the Fall CIO Summit in Baltimore on September 21st.

You can read the first part of this POST here.

Enterprise Service Bus

An enterprise service bus (ESB) is a software architecture model used for designing and implementing communication between mutually interacting software applications in a service-oriented architecture (SOA)

When explaining what an ESB is, I like to use the “Water Main Pipe” analogy. A water pipe / water distribution system receives water from different sources and distributes it to houses; when you open the faucet, you get water, you don’t really care where it is coming from as far as it complies with a pre-established protocol: H2O, odorless, transparent, flavorless and a pre-established interface: Open facet -> get water , Close facet -> stop water.


The ESB was born out of the need to move away from point-to-point custom integrations in order to connect heterogeneous systems. Reducing the custom integration code being spread among application and providing a centralized system to monitor and troubleshoot.





The use of a Service Bus enables a seamless integration of different systems that at the same time can be data consumers and providers. An ESB can also be a broker for different systems of record – like CRM1 and CRM2 – being this completely transparent for the data consumer.

(Systems connected to a service bus can act as data consumers and data providers at the same time).

The beauty of this is the ability to switch systems of record and underlying systems without affecting data consumers – [when correctly implemented] the service bus ensures that the protocols and the services from a consumer perspective remain the same (As if your water provider decided to source the water from somewhere else!)



The ESB provides an unique point of entry and catalog to your Enterprise Services. Centralization and Standardization ease the use for consumers and the driving of best practices.


As pipes and valves in a piping system, the ESB takes care of routing information among connected systems as needed, in a way that is transparent for the consumer. Remember the scenario where we had two CRM systems? Routing capabilities allow consumers to get the right data from both systems.


The goal for a proper ESB implementation is that all the Services available in your catalog “speak” the same language – follow the same protocol – however, that doesn’t mean that the data providers have to “speak” that language. The ESB can act as a translator and a mapper.


In this example, we establish that our Service Bus Services are REST/JSON , also our exposed Account object will look like :

AccountId : 1234,
Name : "Sebastian Hosehold",
Company : "Inspirato LLC"

and our exposed Bill object will look like :

BillId : "XYZ123",
Total : 123.23,
Items : 12

This is what the consumers – like the Web App – will be accessing.

However, let’s suppose that the CRM system exposes data to the ESB in REST/XML and the Account object looks like:

<FamilyName>Sebastian Hosehold</FamilyName>
<Company>Inspirato LLC</Company> 

Last but not least the Billing system exposes data to the ESB with  SOAP services.

The protocol conversion an mapping allows the ESB to not only convert SOAP and REST/XML into REST/JSON, but also re map properties to new properties (i.e. CMRFamily_ID -> AccountId).

It is important to notice that when the data providers – CMR and Billing systems – act as data consumers, ideally, they access the services in the catalog with the protocol defined for the ESB, in this case REST/JSON.


This feature allows to build some “cushion” with the underlying systems – data providers – and also build a “retry” strategy.


Centralized security pattern unified to all consumers. Also centralized access control and audit.


Despite this is not necessarily a part of every ESB product, some of them offer orchestration add ons. Basically an orchestration is the coordination of data consumption and transformation that happens when a service is called. They are different theories related to this subject “should ESB orchestrations drive business processes (like BPEL)?”


This is a list of few ESB offerings. I will not be expressing any evaluation or opinion on the products this time.









We started with a monolithic application connecting and orchestrating 5 different systems. Luckily it was a hub-spoke design so our Metcalfe value for the network was still low.


It took us 4 months to “service enable” our legacy systems and 2 more to orchestrate few of the services.


We finished version 1 just to learn that version 2 will have to come soon.


Every time we design a feature, we make sure that a Service Specification is part of the Acceptance Criteria.


We wanted to keep our services lean and without much complexity and overhead looking forward to our mobile platform.



Remember that SOA is not necessarily a synonym for Web services.


SOA is a way to get where you want to be, it is an architectural guideline. It is not a product! You do not buy SOA, you do not build SOA.


Come up with a good strategy and spend some time thinking about your base components (like security, versioning and naming standards – you won’t be able to change that often in the future). Then be agile, fail fast and work with MVP releases.


It doesn’t matter if you decided to cache data in multiple systems for the sake of performance but you cannot have more than one system being responsible for the same data point! Think on business terms, not technology terms, who is going to be responsible for maintaining that data and which system they are going to use.


Break down business functions into macro-level services and understand the relationships between them. Don’t think about software architecture, think about business architecture: billing, ordering, distribution, etc.


Do not build things for a particular consumer, build things for all the consumers (the ones you have and the ones to come). The perfect catalog of services or the perfect API is self-documented, you don’t need to explain how to code against it.


You will have to fight some fundamentalist software architects. Sometimes what is correct (like a canonical model) does not perform. I am not saying to go crazy and have 10 definitions for the same object, but think on ways to lighten your payloads.


Version you services from day one, part of being agile means that they are going to change (sometimes too often). Salesforce for example, has never decommissioned an API version – they currently have more than 30.


The use of a service bus brings with it the implementation of a single point of failure. Make sure you have a platform that can scale with load, have a failover system in place and do not get too crazy with orchestrations – orchestrate in the ESB only what makes sense.


Enterprise Service Bus – Wikipedia







This is the first post of a series based on a talk I gave at the Fall CIO Summit in Baltimore on September 21st.

Find the second part of this POST here.


We currently live in a connected world : Internet Of Things, Native Mobile Applications, Off-the-Shelf Cloud Platforms, Legacy Systems, etc. Getting the right DATA from point A to point B at the right time has increasingly become a challenge. When is time to rethink our technology ecosystem? How to leverage the power of cloud platforms working in a seamless integration with our legacy applications? What is Service Oriented Architecture and how that applies to my company?

The purpose of this post is to give a 30.000 feet view on this topic to encourage debate and further research.


We live in a connected world: Internet Of Things, Native Mobile Applications, Off-the-Shelf Cloud Platforms, Legacy Systems, etc. Getting the right DATA from point A to point B at the right time has increasingly become a challenge. Even more challenging, there is no limit on how fast we expect data to travel, well I guess the limit is “Real Time”.

When I weight myself in my Fitbit Aria every morning, I want those data point to be ready to be analyzed in my iOS app 5 seconds later. In a less frivolous example, when a customer buys a product, we want to be alerted real-time, what is more, we want our warehouse, distribution center and accounting to get the data that is relevant to each of them REAL TIME.


John started his own company …

On day 1 he noticed he needed to keep track of his customers and that old notepad is not going to be enough, so after some research he founds himself owning few licenses for Microsoft Dynamics.

On day 2 he realizes he will have to pay taxes (you know, death and taxes), he needs a Billing System, and there is John owning a brand new instance of Quickbooks. But, his billing data does not make sense without his customer data… And there it goes the first integration.

On day 3 his pal Mary builds a custom Inventory System for him and also a custom integration with the Ordering System he just bought.

Days go by and John keeps growing his company, as well as his Technology footprint, he also has a cloud Sales System and many more.

Data only makes sense in the context of other data and I don’t think I need to reiterate on the REAL TIME dilema… do you see where I am going?


John Incorporated kept growing and after two years he acquired a second company …


At this point John’s IT department has to maintain multiple systems, not unified systems of records and a scenario where we could apply Metcalfe’s Law to quantify the value of the point-to-point custom integrations.

First, how do we enabled those systems to talk with each other and how we plan for that? Also how we do that in a way that makes sense, and the output of the project is something that can be re used?

Second, how do avoid the Metcalfe / spaghetti linking / ball of mud problem?




SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. Some describe SOA as an IT infrastructure for business enablement while others look to SOA for increasing the efficiency of IT. In many ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant. Six blind men from Indostan encounter an elephant – each of the men then describes the elephant a bit differently because they are influenced by their individual experiences:

  • The man touching the trunk believes it to be a snake
  • The man touching the tusk believes it to be a spear
  • The man touching the ear believes it to be a fan
  • The man touching the elephant’s side believes it to be a wall
  • The man touching the tail believes it to be a rope
  • The man touching the legs believes they are trees.

The blind men then engage in a series of debates about what they believe are facing them:

“…And so these men of Indostan

Disputed loud and long,

Each in his own opinion

Exceeding stiff and strong,

Though each was partly in the right,

And all were in the wrong!”

In many ways Mr. Saxe’s poem has become a prophecy for SOA. Industry analysts, pundits, bloggers and reporters engage each other in an ongoing, never-ending debate about what is or isn’t SOA. Like Mr. Saxe’s blind men, people have correctly identified many of the capabilities of SOA but largely fail to communicate the concept as a whole. The challenge of defining SOA has become so important that various vendor consortia and standards organizations have launched initiatives to try and answer the question “What is SOA?”

For the sake of this blog we will use Google’s software definition for SOA :

“A serviceoriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.”

The architectural concepts associated with SOA are not new – many have evolved from ideas originally introduced by CORBA, DCOM, DCE and others. Unlike these previous initiatives, the key promise of SOA is to enable agile business processes via open, standards-based interoperability.

SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought – the end solution is likely to be composed of services developed in different programming languages, hosted on disparate platforms with a variety of security models and business processes. I want to emphasize on the fact that SOA is an architectural approach and not an implementation, confusing SOA with an implementation style without proper planning can lead to disastrous results.



As in any other technology trend, SOA is full of Buzz words (and acronyms) so let’s cover few of them.

API – Application Programming Interface

Anybody that has done software development should be familiar with APIs. The concept has been around since the 50s . Old school windows developers – like me- have experienced APIs in the form of DLLs.

APIs are basically software building blocks, however these blocks are not anymore restricted to tightly coupled components of our applications. Cloud/Web APIs are made available by other companies for your use (sometimes for free, sometimes not): Mapping APIs, Payment APIs, CRM APIs, etc. With several benefits, like realtime data updates, realtime results and the fact that you don’t have to worry about hosting massive amounts of data. In other scenarios -where the software is still hosted in house- APIs allow you to leverage data on those systems.

Thing of Uber, their platform has been built using third party systems: mapping, payments, CRM, etc.

Companies (and their Engineering teams) can now focus on building software that serves their core business while leveraging third party specialized products through API integrations.


A Webservice is defined as any piece of software that makes itself available over the network, using open protocols. Microservices on the other hand is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs (Ordering Microservices, User Microservices, Inventory Microservices, etc). This is not a new concept, the pattern has been around for a while.


Simple Object Access Protocol vs Representation Estate Transfer. As with most of technology comparisons of this style, and despite which some architects will tell you, there is no winner; and the right answer is “it all depends!”.

REST is based on Resources and in few HTTP based actions over them (POST, PUT, PATCH, DELETE, GET). SOAP is based on Service actions (UpdateStatus, RecalculateAccount, etc).

REST is “lighter” and requires less overhead, responses/data can be cached hence it is faster. It works great with Javascript frameworks and that is one of the reasons why is trending up.

SOAP on the other hand, requires more initialization overhead, however it provides enhanced security mechanisms (WS-Security), ACID transactions insurance, delivery acknowledgement and many others.

As a summary, I would use REST for most of my application, unless I have to build a high security application, like a banking application.


Another endless debate. XML is highly structured, can be validated and transformed on the fly and offers 12 defined types, but is also highly redundant.

JSON on the other hand is lean (and mean), offers fewer types and it can be interpreted out of the box by Javascript frameworks.


Service Oriented Architecture

Microservices – Martin Fowler



My First Post

I’ve been involved in the software scene for over 25 years, actively working for different companies for at least 15. The good thing about this job is that you never get to a “I’ve seen all, I’ve done all” place and there are always new things to learn and new things to try. This 25 years adventure has taken me through different experiences and I think it is a good time to start sharing.

This is the first of hopefully many posts that will cover a broad range of topics: write ups from talks I’ve been part of, personal opinions and experiences related to software and product development, product reviews, SD methodologies, and why not, some coding (YES I WILL ALWAYS BE A DEVELOPER!)

I apologizes in advance as English is not my first language, however, it is the most spoken language in the Tech community, I will do my best to make sense,,,, most of the time.

Thanks for reading!

Blog at

Up ↑