You’re doing it “all wrong”, you “should be more open-minded”, and you’re “using the wrong tools”. Believe it or not, these are the things you want to hear when you walk past the meeting room where your developers are working on your new ESB integration tool. Diversity is said to be the most important feature of every great team, and sad but true: diversity comes with confrontation. So how do you assemble this perfect mix of skills, creativity and conflict and turn them into your ultimate ESB development team? We’ll tell you in this blog.
Who will do the hard work?
You’ve realized your IT data infrastructure has become too complex and interdependent. You want to change this situation by purchasing an Enterprise Service Bus that will exchange and forward messages like a multifunctional mailman. Brilliant idea. But as soon as the ESB selection procedure starts, questions will rise. What are important ESB requirements? How will you implement it? And more important: who will implement it? When you’re not a techie yourself, figuring out who you should take on board for the implementation part is tough. Integration of systems not only affects IT, but will also impact the way the people in your company do their job. This means you need people from different disciplines and with different skills.
The ultimate ESB development team
If you ask us, your ultimate ESB development team consists of at least these four key figures:
- Enterprise architect
- Solution architect
- Information architect
- Developers
The Enterprise Architect
First up is the Enterprise Architect. He (or she; don’t work with people that think men hold the rights to IT skills) bridges the gap between the business and IT. He knows what’s going on in both camps, and uses this information to make sure that business requirements are translated into the so-called reference architecture, which is the IT architecture you want your company to have eventually. The Enterprise Architect doesn’t set up this architecture himself, but figures out what it should do, which benefits it must bring and what the implementation project will cost. He then reports back to the product owner or management, which is responsible for the end result. You might say the Enterprise Architect is a non-tech function, focusing on the business rather than the technical details of the ESB project.
Can be recognized by: Jack-of-all-trades, decisive, great people skills, must have been a teacher in a former life
The Solution Architect
Based on the bigger picture as drawn by the Enterprise Architect, the Solution Architect makes the actual drawings of the connections that need to be made. He will turn all of the business requirements into actual features and monitors the implementation of the ESB step by step. The Solution Architect will have regular meetings with the Enterprise Architect to see if everything goes according to plan. These meetings can be tough, as the business requirements cannot always be met in the way they were formulated, meaning the Solution Architect must come up with alternatives and pitch them to the Enterprise Architect, who in turn has to report back to the product owner. The Solution Architect has to stand firm, though, as he cannot burden his development team with impossible requirements.
Can be recognized by: organized, demanding, highly intelligent, brilliant but rightfully stubborn
The Information Architect
Like we explained in an earlier blog, not all systems are ready to communicate. Some of them need help, maybe in the form of a CDM (Canonical Data Model), which translates messages into a common format. The Information Architect thinks about these issues and finds ways around them so that the future ESB can do his job. The Information Architect will report back to the Solution Architect, and advise him on which measures to take.
Can be recognized by: creative, bit of a nerd, gets his inspiration from small talk like you see in TV series
The Developer
So far, not much has happened. The actual implementation is carried out by a team of developers. They build the connections between the applications and make sure everything works according to plan. This means they build, test and monitor the ESB performances long after it’s been installed. Developers are aware of the requirements, but knowing them is not their main concern. They will take all the information derived from the Enterprise Architect, the Solution Architect, and the Information Architect to get the actual implementation done.
Can be recognized by: perfectionist, focused, thorough, consistent
Shopping from your pantry
So where do you find these people? Before you Google “ESB development team needed”, first think about the people you already work with. You probably already have an Enterprise Architect and an Information Architect, as they’re needed for other internal projects too. Solution Architects are usually external, as they’re hired to implement a specific product, like an ESB or an API. Developers are often external too, because of the simple fact you need specialists and extra hands to get the job done. In our experience, a hybrid team of internal and external IT professionals works best, as they’re the perfect mix of specialism and internal insights.
Who will you take on board for the implementation of your integration tool? And why? Let us know by leaving a comment below!
Not sure which ESB tool and vendor to choose? Then read our whitepaper on how to select your perfect ESB match.
