Mo Money Mo Problems...to solve

My current job title is "Technical Pre-Sales Consultant" its pretty self explanatory, but during my career I've worked as a developer, technical lead, consultant, scrum manager, I could probably go on but it would be a pretty boring post. I'll get to the point, the best career title I could assign myself is "problem solver". I just love to solve problems, a simple bug in a piece of code, complex distributed system architecture, or improving  process to accelerate project delivery and maximise margin, I'm not fussy, I'll solve them all. A notorious rapper once versed "Mo money, mo problems", I'm not sure if this makes me normal, but that's music to my ears.

As a technical consultant I'm aware of the benefits of service oriented architecture and agile delivery (when implemented correctly). Mediation between loosely couple distributed systems, small chucks of manageable work, and responding quickly to change. It got me thinking why not try and apply these principals in other areas.

Recently we implemented JIRA for bug tracking, and Confluence for knowledge transfer and configuration management. With our team expanding it seemed sensible to try to add some control and structure to the delivery of our demo application Officecore. 


Now I most likely should be using the enterprise recommend tool, but I'm not, I like Atlassian's stack and I know it fits our requirements. The fact that "I like it" is key, my feeling is that you can impose process on people but if they don't find it workable or user friendly they simply won't use it, or at least won't use it effectively. 
Recently at Sitecore we were treated to a days training on DISC profiling. I find all this fascinating, the ability to gauge your own personality type and identify others is really powerful. Understanding that not everyone thinks like you, and that people are different (and that's not a bad thing) is key to my thoughts on this subject. Why would you expect your entire organisation to have the same opinion of a single application.
Once the framework and services are in place you can push, pull and ultimately share relevant data between these systems and teams, and if you still want a global view of it all, pull it all into a central system and manage and report on it there. Let the integration framework you implement maintain, sync and even transform the data.


So this is where the SOA concept rears it's head. As an organisation why not let teams pick and chose the tools to do their job, be agile, loosen your grip on internal application architecture. 
Gone are the days of needing to buy a server, set it up and then install software on your system before you can start reaping the benefits. These days most companies provide their tools as software as a service. This approach makes it easy to be up and running in minutes, 30 day trials make picking tools a less stressful process, if it isn't what you are looking for, close the account down and try the next one.
Instead of directing your time and focus on picking tools that will suit all, and working out how to implement and manage them globally, instead focus on a strategy for integration and mediation. 
Obviously some control is needed, but advising people to pick from a selection of recommended tools rather than dictating the use of a single one, in my opinion is a better approach. 


Switching focus back to integration, those close to me will know I'm a big fan of Apache Camel, but software as a service vendors such as Zapier have the right idea. React to events and trigger actions on that basis. As long as your tool exposes a web service layer implementing REST you can create a Zapier zap to bridge and mediate between applications. I'm not saying Zapier is the way forward as I've not used it a lot, but I commend the principal and just like what they are doing.



Comments

Popular posts from this blog

Sitecore Unicorn standard values field child ID warnings

Sitecore DMS and Analytics Considerations

Sitecore 8 Rebuilding historical path analyzer maps