January 14, 2023
Kannan Subbiah
FCA | CISA | CGEIT | CCISO | GRC Consulting | Independent Director | Enterprise & Solution Architecture | Former Sr. VP & CTO of MF Utilities | BU Soft Tech | itTrident
Teams celebrate a 10% improvement in efficiency when they should be looking for a 10x improvement in efficiency. Identify key moments in your product lifecycle when it makes sense to step back and identify the substantial changes that can supercharge productivity. My company builds connectors into a huge variety of data sources. At one time, we were writing 5,000 lines of code to create a single connector, which was not sustainable. Now, a single engineer can build a connector in a week with 100 lines of code. We achieved this by designing a new development framework that allows us to exploit commonalities across the connectors we build and by greatly reducing dependencies among engineers. As soon as one engineer needs input from six other engineers to complete a task, productivity takes a massive hit. Here's a thought experiment you can run to help find your own 10x improvement: Imagine your workload scales 10x overnight, and you absolutely must meet this increase without hiring more engineers or working additional hours. How do you do it? An out-of-the-box thought exercise like this can help you radically improve your approach.
While replicability isn’t as important as delivery in a modern environment, where software is often unique to the organisation, it is important to be able to prove effectiveness. At Catapult, we use an upskilling system that we call the Lighthouse Model; whereby we identify a team from the ground-up that can act as a model for the rest of the business and focus first on developing them as a group. By demonstrating the effectiveness of agile as a foundation on which to build software, a Lighthouse team creates a fertile environment, which removes blocks and gathers data to help develop buy-in across the board. All this works. In 2018, the Standish Group established that ‘Agile projects’ are twice as likely to succeed than waterfall projects. In the same study the company notes that 28 per cent of Waterfall projects fail, while only eleven per cent of agile projects meet the same fate. In this context, the metrics of success went beyond whether the project was on time and on budget and considered its outcomes and impact. They looked beyond the delivery against the plan to include the value delivered and customer satisfaction. In essence, they looked for the real meaning of success.
The first thing you might assume is that reliability is synonymous with availability. After all, if a service is up 99% of the time, that means a user can rely on it 99% of the time, right? Obviously, this isn’t the whole story, but it’s worth exploring why. For starters, these simple system health metrics aren’t really so “simple.” Starting with just the Four Golden Signals, you’ll end up with the latency, resource saturation, error rate, and uptime of all your different services. For a complex product, this adds up to a whole lot of numbers. How do you combine and weigh all these metrics? Which are the important ones to watch and prioritize? Judging things like errors and availability can be difficult too. Gray failure, or when a service isn’t working completely but hasn’t totally failed either, can be hard to capture with quantitative metrics. When do you decide when a service is “available enough?” What about a situation where your service performs exactly as intended, but doesn’t align with your customers’ expectations? How do you capture these in your picture of system health? Clearly, there needs to be another layer to this definition of reliability!
领英推荐
I suspect one of the greatest lies ever told in web application development is that if you use an ORM you can avoid writing and understanding SQL, “it’s just an implementation detail”. That might be true at first, but once you go beyond the basics that falls away quickly. ... It’s much better to let the database do this kind of filtering. After all, it’s what all of the clever folk who work on databases spend a lot of time and effort optimising. For most ORMs you have the option of writing analogues to SQL which can get you quite a long way. For example, JPA has JPQL and Hibernate has HQL. These let you build abstracted queries that should work on all databases that your ORM supports. The implication of this is that your team needs to embrace SQL and understand how to use it, rather than avoiding it by using application code instead. To dispel a common source of anxiety on this: you don’t need to be a SQL guru to get started and become familiar with what you will need for the vast majority of your implementation requirements. There are also excellent resources and books available, I will link some below.?
An SCP enlists employees from all different disciplines across a company (HR, marketing, finance, etc.) for focused cybersecurity training and guidance. These security champions then become the contact point and voice for cybersecurity within their various departments or offices alongside their main role. They help to advise on, embed and reinforce good security practices with their colleagues. This makes security advice more relatable and accessible, avoiding the “us versus them” attitude that can sometimes exist between employees and traditional enterprise security teams. It’s easier for a colleague to explain a security risk or issue to a co-worker than it is for a security pro whom the co-worker has never met. The security champion’s role is a little like that of a department’s fire marshal. In the same way that the marshal doesn’t need to be a specialist in firefighting, the security champion doesn’t need to be an IT or infosec pro; they just need to know how their colleagues work, what the security risks are within their department or team and the common-sense steps to take to mitigate those risks.?
Carolina Klint, risk management leader for continental Europe for insurance broker Marsh, and one of the contributors to the report said that insurance companies were now coming out and saying that “cyber risk is systemic and uninsurable”. That means, in future, companies may not be able to find cover for risks such as ransomware, malware or hacking attacks. “It’s up to the insurance industry and to the capital markets whether or not they find the risk palatable,” she said in an interview with Computer Weekly, “but that is the direction it is moving in.” In recent days, cyber attacks have disrupted the international delivery services of the Royal Mail and infected IT systems at the Guardian newspaper with ransomware. The Global risks report rates cyber warfare and economic conflict as more serious threats to stability than the risks of military confrontation. “There is a real risk that cyber attacks may be targeted at critical infrastructure, health care and public institutions,” said Klint. “And that would have dramatic ramifications in terms of stability.”