Hello and Welcome. I’m Jonathan Gilmartin a professional Software Architect and Developer based in Derby. I specialize in Microsoft Technologies having professionally worked with .NET and C# for many years. From my development experience I have produced many types of software for a wide range of clients and industries. These range from Enterprise level websites that attract millions of monthly visits, 3rd party API Integrations, WebAPI Rest Services, automation applications and everything in between. From my Architecture experience I have become an expert with Azure and DevOps. I can ensure your application is not only developed correctly using best practices but also continually deliverable and hosted in Azure. I am also very confident to propose investing in a technology, presenting a system and infrastructure design to business leaders or large audiences.
I have learned from experience as an Architect the old saying “fail to plan, plan to fail” is very true. A couple of days planning and discussing round a whiteboard can save months of pain later in the project’s development cycle. I have learned from experience as an Architect the old saying “fail to plan, plan to fail” is very true. A couple of days planning and discussing round a whiteboard can save months of pain later in the project’s development cycle. Developers can be very eager and passionate and as the architect although these are desirable traits the “rains need to be pulled in” to ensure the code is to a certified standard and the tasks and user stories all fit the requirements.
For the past 2 years I have been extensively working with Sitecore on a large migration project from an obscure and legacy CMS to Sitecore 9.02 hosted in a Scaled PaaS Azure Environment. Since working with Sitecore I am officially recognized as a certified Sitecore developer completing the exam in April 2018. My key Skill with Sitecore is DevOps and Azure, although I’m also skilled at Sitecore development using Helix.
At time of writing my current assignment is creating a Web Application using a Micorservices architecture. This uses PaaS AppService’s in Azure and SOLR for Enterprise search. I’ve specifically designed the system so each service is developed at the domain level (search, customers, etc) so not to overcomplicate things with services that are too granular. I have also documented a development and solution standard so every service from an architectural perspective is identical and only the core business logic is unique. This means that any developer who is working on a microservice will easily adapt to working on a different service.
My ethos today regarding Software Development is simplicity and standardization. Software systems are complex by their very nature let’s not add any additional complexity than we need. It’s critical to plan and research your chosen technology before you start any development. Can you say with confidence that your tech stack and architecture is the best choice for the software solution you will be developing? An established, tried and tested technology is always the best choice to ensure reliability and wide spread developer support and adoption. Nothing will slow down your development quicker than trying to google issues your having with a technology which isn’t widely used.
Just because a technology is the “New Thing” certainly doesn’t mean it’s the right choice. Just speak to any developer who decided on using a NoSQL technology when a traditional SQL Database would have been far more suitable.
Just because a technology is the “New Thing” certainly doesn’t mean it’s the right choice. Just speak to any developer who decided on using a NoSQL technology when a traditional SQL Database would have been far more suitable. I’ve seen many times in the past projects fail due to developers without IT leadership trying to implementing technologies that are not needed which in turn increases complexity or are overkill for the problem they are trying to solve. I’ve worked with projects that have been developed with a ridiculous amount of 3rd party libraries and the result is an undocumented mess of spaghetti code where the only cost-effective solution is a full rewrite.
Enforcing a standard for code conventions, database design and solution architecture significantly reduces future technical debt while ensuring your code is easily understood by new developers joining the business. It also makes it easier to add new functionality. The majority of applications are monolithic where everything is one solution. This is fine for small applications but becomes problematic for large applications where scaling becomes difficult and expensive. I’ve seen it before where a monolithic application needs particular functionality to be scaled, but the only way is to scale the entire application. Instead I always try and decouple applications into REST based WebAPI Services so they can be independently scaled but also independently developed. Developers only need to know the service rather than the application as a whole.