As an assignment in the Strategy and Marketing course of my ongoing MBA studies we were required to give our personal view of what strategy is and I thought I should publish the result here. Part of the reading for the assignment included five articles from Harvard Business Review, three by Michel Porter and two by Kathleen Eisenhardt.
The three articles by Porter takes a high level perspective, defining strategy in terms of the nation state, the industry as a whole and strategy at the highest level of the enterprise. Essentially this is a top-down perspective, or perhaps one could call it outside-in. For Porter strategy is about making conscious trade-offs (what not to do), supported by a unique set of activities that reinforce each other and are difficult to reproduce, all in all creating a unique strategic position giving a sustainable competitive advantage (What is Strategy, p 70).
In the two articles by Eisenhardt et al strategy is something emergent, arising from the pattern of activities (patching and the application of simple rules). It is more about the internal strategy process than finding a strategic position. Essentially this is more of a bottoms-up perspective on strategy, or perhaps one could say inside-out.
Porter and Eisenhardt also differ in the time scale of strategy. Strategy in the eyes of Porter is long term; if a strategy does not lead to a sustainable advantage with a high performance outcome, it is not strategy or at least not successful strategy. As a counter point, the two articles by Eisenhardt et al discuss strategy with a shorter horizon (“internet time”).
The blog has been down for a long time but is now on-line again!
Recently a couple of New York college students made a stir when they announced that they would write an open source and distributed social network server as an alternative to Facebook. This is really in the true spirit of the internet, where everyone can set up his or her own server and have them commicate, compare e.g. how email works. Incidentally, this is the way Instant Messaging should work but only SIP and Jabber (used by e.g. Google Talk) actually implement. Evidently they have raised about $170 000 in three weeks using Kickstarter, their initial target was $10 000.
I sympathize 100% with their stated goals and will make sure I set up a Diaspora Seed once they make their first release.
More information on the Diaspora blog.
As you may know Agile software development is inspired by the principles of Lean Manufacturing which in turn is derived from the Toyota Production System (TPS). One Agile methodology, Lean Software Development even borrows the name Lean to make the connection explicit. Since the principles in Lean and TPS have much in common with how Japanese always have approached manufacturing and that TPS supposedly permeates the whole of Toyota, it comes as a real surprise that Toyota uses a waterfall process for software development!
At the thanksgiving dinner of a friend from work I tried to explain REST-ful applications – and I think I failed miserably. Even though there are plenty of good introductions out there I felt I needed to organize my thoughts a bit. Having some spare time on the train on the way home I made a second, more structured attempt in the form of this blog post.
Imagine you are a web developer and is asked by a friend with a travel agency to help out create a web site for his company. Among the services on the site is a small web application for searching for hotels recommended by the agency. These hotels have been carefully vetted for the agency’s customer segment and useful hotel information is stored in a database.
In a famous post from January this year (which I missed) Ann Thomas Manes declares SOA dead. She is a Reasearch Director within the Burton Group, has worked with SOA in the Burton Group and elsewhere, and is a co-author of the WS-* specifications.
The post has sparked fierce defense from vendors like Oracle. During the half day SOA Architect forum in Geneva this Tuesday, Oracle spent the first seminar repeating that “SOA is not dead” like a mantra, I guess in order to reinforce the message. It seemed to be one of the mayor points they wanted to get across.
In the Java world there are several ways of handling dependencies between project components in a shared development environment. Maven is a generic build tool that creates a standardized way of creating, building and publishing component artifacts. Dependencies between the different components are declared in a Maven build file and Maven automatically downloads the dependencies and all transient dependencies recursively from local or public repositories. Repositories can be local to a particular developer, department or enterprise; or they can be public, available to the development community at large. Ivy is another utility which focus solely on dependency management. It is positioned as the lean and simple alternative to Maven which focus only on the dependency aspects and that integrates well with Ant (the generic java build tool).
For .NET based solutions there does not seem to be neither a Maven nor Ivy style dependency management system for development. This article outlines a solution to dependency management in the .NET world that has been inspired by the Maven and Ivy.
A while ago I reflected on Object Oriented Programming and the fact that it really is more about classes than objects. Reading up on Newspeak, the new langugage proposed by Gilad Bracha I came across Self, one of the language on which Newspeak is indebted to. In Self no classes exists, only objects. More on this later.
Crystal Clear is the smallest of a series of methodologies for software development, all created by Alistair Cockburn. It is smallest in the sense of the project size it addresses (up to eight developers) and in the number of things it prescribes. Other Methodologies, deriving their names from the colors of crystal, are increasingly heavier. They all share the same “DNA” though, which is “expressed” differently with increasing project size and criticality, the latter meaning the higher cost in terms of money or at the extreme human life.
The book in itself has an interesting setup where each chapter addresses an aspect of Crystal Clear in a different format, tone and style. The purpose of this setup is to appeal to a large audience where each reader can find at least one chapter that conveys the essence of Crystal Clear to her clearly. The most peculiar chapter is probably the one where an ignorant Alistair queries a fictive Crystal character over a series of letters about the inner workings of a successful software development team; thus mimicking a Socratic dialogue. I am not sure this stunt works in practice, but at least true to the intent some chapters work better for me than others… All chapters are, however, still written in an easy and personal prose.
In Beyond Software Architecture, Luke Hohmann addresses all things paramount to software product development that are usually not covered in books on software development. These things include licensing, software protection, branding, marketing and business plans and how they relate to the technical architecture and more. Every developer or architect that has been around a few projects probably will probably recognize the importance of some, if not all of these areas, in relation to creating and sustaining a winning solution.
The first and probably most important topic covered is the relation between the business model and the technical architecture. It is really an understatement to claim that the chosen business model has a serious and real impact on the technical architecture – it should be self evident that there the architecture will look quite different in an ASP scenario and a single user desktop application… Less self evident is the relation between the business plan and the technical architecture. What business segments are being targeted and in which order really does bear on the architecture. Each business segment will have its particular needs to be addressed as features in the software solution. The order is important since it will help spell out the technical roadmap for future releases.
The book covers a large number of topics and gives advice on a number of specific issues, too many to cover here. I have chosen but a few that have stuck after finishing the book.