Search

Sebastian Gnagnarella

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

Category

Enterprise Architecture

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.

Advertisements

THE ROAD TO A CONNECTED TECHNOLOGY ECO- SYSTEM (Part 2)

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.

Picture1

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.

REMEMBER THIS …?

2015-09-28_18-29-02

WHAT ABOUT THIS …?

2015-09-28_18-30-43

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!)

FEW BENEFITS OF ESBs

SINGLE CATALOG OF SERVICES

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.

ROUTING

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.

PROTOCOL CONVERSION AND MAPPING

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.

2015-09-29_11-47-47

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:

<Account>
<CMRFamily_ID>1234</CMRFamily_ID>
<FamilyName>Sebastian Hosehold</FamilyName>
<Company>Inspirato LLC</Company> 
</Account>

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.

QUEUING

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

SECURITY

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

SERVICES CHOREOGRAPHY AND ORCHESTRATION

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)?”

PRODUCTS IN THE MARKET

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

TOP TIER

Picture1

MID-TIER / PAAS

Picture2

OPEN SOURCE

Picture3

OUR EXPERIENCE AT INSPIRATO

WE’VE BEEN THERE

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.

THE PROJECT WAS TRIGGERED WHEN WE DECIDED TO BUILD A MOBILE APP
IT TAKES TIME

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

WE ARE NOT DONE

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

SOA IS PART OF OUR TECH FOOTPRINT

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

WE DECIDED FOR REST / JSON

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

FINAL THOUGHTS

IT IS NOT ONLY ABOUT WEB SERVICES

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

SOA IS A MEAN NOT A RESULT

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.

PLAN BUT DO NOT OVER ENGINEER

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.

IDENTIFY SYSTEMS OF RECORD

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.

BUSINESS FIRST THINKING

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.

ABSTRACTION, REUSABILITY, GRANULARITY AND STANDARIZATION

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.

ACCEPT SOME TRADE OFFs IN LIUE OF PERFORMANCE

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.

VERSIONING

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.

SINGLE POINT OF FAILURE

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.


RESOURCES

Enterprise Service Bus – Wikipedia

TIBCO

ORACLE

MULESOFT

DELL-BOOMI

CLOUD ELEMENTS

THE ROAD TO A CONNECTED TECHNOLOGY ECO- SYSTEM

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.


OUTLINE

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.

THE PROBLEM

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.

AN EXAMPLE TO RELATE WITH

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?

2015-09-24_14-03-25

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

2015-09-24_14-08-31

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?

SERVICE ORIENTED ARCHITECTURE (SOA) 

WHAT IS IT?

2015-09-24_14-30-38

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.

FEW BUZZ WORDS

2015-09-24_14-43-43

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.

WEBSERVICE / MICROSERVICE

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.

SOAP vs REST

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.

JSON vs XML

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.


RESOURCES

Service Oriented Architecture

Microservices – Martin Fowler

SOAP vs REST

XML vs JSON

Create a free website or blog at WordPress.com.

Up ↑