{"id":125,"date":"2024-05-03T14:40:37","date_gmt":"2024-05-03T14:40:37","guid":{"rendered":"https:\/\/www.simplybusiness.co.uk\/about-us\/careers\/architecture-manifesto\/"},"modified":"2024-05-29T05:19:40","modified_gmt":"2024-05-29T05:19:40","slug":"architecture-manifesto","status":"publish","type":"page","link":"https:\/\/www.simplybusiness.co.uk\/about-us\/careers\/architecture-manifesto\/","title":{"rendered":"Architecture Manifesto"},"content":{"rendered":"\n
\n

Architecture Manifesto<\/h1>\n<\/div>\n\n\n\n

Simply Business Architecture Manifesto<\/h2>\n\n\n\n

Enable and empower the business<\/h3>\n\n\n\n

We believe we can dramatically improve the business by creating systems and processes that allow us to rapidly test and modify our product and service offerings. Our goal is to lead with our technology rather than work around its limitations. This principle forced us to re-platform the whole business. We were unable to make changes to our old platform and a number of initiatives were executed but failed to work. On the new platform, we have proven we can initiate numerous changes quickly and seamlessly.<\/p>\n\n\n\n

Enable and empower the development team<\/h3>\n\n\n\n

We believe that freeing up talented people to work on a flexible platform is far more important than strict standards and locked down approaches. This leads naturally to agile and continuous delivery which enables rapid turnaround in a decentralized manner.<\/p>\n\n\n\n

Agile\/Kanban<\/h3>\n\n\n\n

Agile\u2019s power is in putting the result above the process, and enabling individuals to work collaboratively to achieve goals in small increments. The benefits of the approach are amply documented, but knowing where you stand on a deliverable, and the ability to change course mid-flight are powerful results of using the approach. We\u2019ve moved to Kanban to reduce the waste of idle teams. We have reorganised the entire organization to form cross-functional teams, with products having stakeholder engagement across the business. This has lead to us create the Start-Start-Start process which ensures stories are not began working on without the correct business stakeholders involved.<\/p>\n\n\n\n

Build-Measure-Learn<\/h3>\n\n\n\n

We believe that by using a data driven and scientific (experimental) approach to growing our business, we can continue to transform business insurance. There are challenges here, but by doing Build Measure Learn we avoid the HIPPO problem (Highest Paid Person\u2019s Opinion) and the assertion that \u2018we just need to do this\u2019 or \u2018it\u2019s obvious this will help\u2019, followed by the inevitable conclusion that the impact could not be measured.<\/p>\n\n\n\n

Build the suit<\/h3>\n\n\n\n

Most people think of technology as a black box solution. Their idea is that you put the new (and ‘perfect’) system in place, and then walk out the door, turn off the lights and everything runs perfectly day in and day out – we know this isn\u2019t the case.<\/p>\n\n\n\n

We find our software needs constant tweaks as the needs of our business change. Even more significantly, we aren\u2019t able to identify complex business rules from the start. So instead of building the robot (a fully automated algorithm that knows all the ins and outs of the entire business process), we build a suit. We start with a manual process and then build on top, one small feature at a time. We use the Pull Methodology, which states that new features should be \u2018pulled in\u2019 by the users. As new functionality is needed, we build a very simple version and then build on top of it.<\/p>\n\n\n\n

Define Business Rules<\/h3>\n\n\n\n

All too frequently, we have run into the situation where poor code, though on the surface seems due to bad coding practice, has stemmed directly because the business rules (how we expected the feature to work) were never defined properly. The code then grows unruly because bugs are fixed without reference to how we want the system to operate. Each developer that touches the code comes up with their own definition of what they feel is the correct solution in the specific area where they are working. This can lead directly to bad code. We ensure we properly define business rules so that each developer can avoid this scenario.<\/p>\n\n\n\n

Github instead of configuration<\/h3>\n\n\n\n

Over time we came to realize that git (and especially GitHub) can be used as a powerful configuration management tool. We also realized that far too much emphasis in existing software practice is focused on creating systems that once built don\u2019t need developer involvement. We see this \u2018orthodoxy\u2019 as a waste. What we actually want is that required changes to configuration (whether of an exclusively metadata variety or requiring code changes) are able to occur as quickly and easily as possible. We\u2019ve found that a large number of changes, in the rapidly changing world we operate in, inevitably require not just config changes but also code changes.<\/p>\n\n\n\n

We have also found that by using Pull Requests (via branching) in Github as well as a robust sign-off and testing process, we can allow business users to make code changes to our applications without in any way compromising the quality of our releases.<\/p>\n\n\n\n

Furthermore, we have built a set of DSL\u2019s (Domain Specific Languages) which allow business users to write code they can understand. Because of these changes, we have eliminated the need to write complex admin systems, and are able to make configuration changes in a TDD manner. This means that business users will first write tests to validate that changes to pricing models (for example) can produce the correct calculations, and then write the DSL to modify the pricing model to fulfil the tests. This model is unquestionably radical, and is working well for us.<\/p>\n\n\n\n

95-5 Rule<\/h3>\n\n\n\n

Many people who have been in the tech industry a long time are familiar with the 80-20 rule. Usually, the 80-20 rule is related to choosing third party applications when putting together an architecture for a particular technical solution. The rule states that an application (or service) is suitable for the problem at hand if it does 80% of what is needed, and the developers and analysts will (only) need to customize 20%. In the new world, with powerful scripting languages and frameworks like Ruby on Rails, the effort to build from scratch has dropped dramatically. Therefore we adjusted this age old rule. Our new rule recognizes that any time you need to build more than 5% of the functionality, you might as well build it yourself. We call it the 95-5 rule. This has massive implications. It can modify choices made on functionality, as well as choices made on application\/tool selection.<\/p>\n\n\n\n

Work as one Team<\/h3>\n\n\n\n

We know that our projects succeed as a function of how aligned all the stakeholders are. Project teams as a whole – not just the tech or business components – are responsible for the success of the project. We work as one team as we know from experience that dedication and collaboration leads to successful outcomes.<\/p>\n\n\n\n

Great People<\/h3>\n\n\n\n

At the heart of our manifesto are great people. If you hire great people, they have the passion, ability and desire to create great solutions. Without them, it is hard to get good results. We give our people autonomy because we know that great people often know things that others don\u2019t.<\/a><\/a><\/p>\n\n\n\n

\n

A free monthly newsletter with the latest news and tools for small businesses and landlords.<\/p>\n\n\n\n

\n
Subscribe to our newsletter<\/a><\/div>\n<\/div>\n\n\n\n