Archive for June, 2015

we don’t really have a strategy

June 12th, 2015 No comments

It is said a strategy has to have these components:

    • Purpose
    • Plan
    • Doable series of actions
    • Measurable goal(s)
    • A narrative

To this, I’d add that it is important as well to weight side effects as well as the validity of those goals. It could well be that a strategy could be beneficial in the short term, and disastrous in the long term, or cause a lot more damage to third parties (therefore, it is externalized and seems much less important) than the benefit it may bring.

Let me call them “risks” in a generic way. So a strategy must be iterative and open to revision at all times, if unforeseen results appear from those goals. Don’t fall for the trap of naive rationalization or the belief – wildly spread in politics today – of omniscience and infallibility.  Most often, I think we do not know how to do strategy.  And that probably we even can’t. It’s an illusion.

In both the business and the politics worlds, two elements are magnified and the important – and hard – stuff, neglected. We love simplified narratives with clear – albeit fallacious – causal relations, and we love the apparent purpose we made up in our heads – that is, we are focusing on the fairy-tale results, the dreamy end, the wishy-washy grand statements, and we want to obviate the hard part, which is designing your plan, deciding what work and efforts are needed, also to realistically assess if it’s doable at all in your context and then decide how you will measure success (or the lack thereof, in order to learn).

Assessment and measurement are to be done with metrics and numbers. These are notoriously and largely absent from political manifest and party programs for example – and nobody seems to be shocked by that glaring omission -, which are the perfect showcase of how the public at large prefers to focus on the narrative, the seduction part, and forget about the hard part (as bold as unsubstantiated slogans or mission statements as “reclaim the city for the citizens”, “build a fairer more egalitarian society”, for example), and that is probably because politics is not only the art of the possible, but is as well about deceiving and seducing in order to nudge oneself and one own’s clique into a rent-seeking position of power.

But the business world is also full of grand purposes, transformation projects and strategies (a lot of them digital, these days) that remain just that, dreams and a lot of meetings.  A strategy should inspire, yes, but before that, you need to perspire and work hard to come up with one.  One that is backed by cold hard facts, by sensible reasoning and assessment, by taking into account what worked and failed in the past as well.  It does not have to be something very complicated. Something like this is probably enough to get started.

NARRATIVE Developing business CRUD applications for our clients can be very fun!
PURPOSE Position our company as a top software development boutique
PLAN Rather than rely on price-based race to the bottom competition, compete on quality and real value
ACTIONS Invest in quality training in bleeding-edge technology
Partner with great companies
and/or open source projects
position ourselves in the radar by writing blogs
speaking at conferences
publishing books or papers
MEASURABLE GOALS Are we getting more contracts?
Are we working with companies perceived to be leaders? what are your desired partners?
Have we moved into or towards thought-leader territory? if yes, how can you prove it?
Have we been able to raise fees and improve profit in projects? How much?
Are we delivering better and faster? Percentages, please?
RISKS Hard work is more prone to quitting
Complacency and relax
Harder to maintain momentum

I just came up with this in the time it takes to actually write it, so please excuse the simplicity, but I guess you have seen plenty of documents full of the three first points, and not so many of the other three, especially the last two.

Without those, a strategy is worthless.

Categories: rants, strategy Tags: ,

simple request weight

June 12th, 2015 No comments

This is just a sketch of an idea for all manner of web-based applications, LOB applications or otherwise. The idea is that requests to the server should provide or be enriched with some sort of metadata that would enable the server to inspect a given request and decide on the configured importance of that request. This could either be done from the client side of the application, which then should have some modicum of business knowledge so that all requests to the server are wrapped or enriched with some metadata describing a degree of priority, for example, or some sort of indicator.

This is not very new, as that wrapping might reming of old-style SOAP enveloping. Also the idea of some sort of metada or cataloguing of requests is similar to what you find implemented in certain frameworks, for example, actor frameworks like Akka.NET have a similar mechanism in virtue of which, system messages can jump to the top of the queue for priority processing. If we want to keep the client side free from these troubles and the necessary knowledge, other strategies can be followed. This wrapping or enriching of requests could be outsourced to some dispatcher component that centralizes and takes care of that task.

Obviously you need that this extra step does not become some sort of bottleneck when processing a lot of requests. Given that the task is well-scoped and stateless, it is easy to think of this as a fast web service, even a windows service – if that suits your application typology -, or some cloud-based job, that could keep it’s necessary configuration or rules in a small memory cache, and even, with some extra work, be able to be reconfigured while live. In an even simpler way, we could just create some configuration database so that the server side can actually look at a request and then decide. In the simplest scenario, the URL could already give a lot of information for decision, especially if you have a well-crafted web api design. For example, you could choose to server first people who are using v2 of your api (www.mygreatcompany/api/v2/product/123) instead of those still using the v1, or you could inspect metadata to understand if your user is a paying platinum member instead of a bronze free account.

Or you could discrimate by locale. If you have 0 presence in China, and you suddenly get a lot of traffic from China, maybe you don’t want to pay that much attention to that (leaving other security concerns aside here). Similarly, in some applications you could have “system” messages that you want to have priority, for example, refreshing a piece of data held in cache immediately. To make this into a configurable, reusable mechanism probably a good way is to configure a simple map or hashtable of identifiers and assigned weights, something along the lines of this one below, even combining different aspects (URL inspection, user metadata, etc) of inspection to better decide on the business weight of a request:

Such a structure would be easy to customize in each application according to needs, so that each could roll out its own requests analyzer according to business needs. This strategy could also be used in conjunction with other patterns, such as an azure priority queue, to which the most important messages could be routed to. I am sure there are holes in this and plenty of room for improvement, but I think the idea could be interesting in many scenarios, and in some of them a simplified approach can do. Overly complicated systems are also expensive, so sometimes, some duct tape can do, at least as an spike, and then if the idea proves good, then learn and refine, of course.

Categories: architecture Tags: