Information Systems Architects should write solid code. Part 1, Why?

I believe that an architect, in the Information Systems world, should be first and foremost a very good programmer. The architect should write code on occasions, it would be better if writing code is actually a habit. When this is the case, the Architect is able to bring a positive influence to the organisation. When this is not the case, the Architect would most probably be less efficient and will find himself/herself regularly in unproductive discussions.

I believe that, in Information Systems environments, an architect should be first and foremost a very good programmer. The architect should write code on occasions, it would be better if writing code is actually a habit. When this is the case, the Architect is able to bring a positive influence to the organisation. When this is not the case, the Architect would most probably be less efficient and will find himself/herself regularly stuck in unproductive discussions. Unfortunately, a non-negligible amount of inefficiencies stem from the Architect’s lack of awareness of the application platforms and code and the engineering activities surrounding them.

This can be proven ab absurdo, but I will provide a simple case to illustrate the point.

In this and subsequent postings, I plan a multi-part posting, I will be using the term Architect to refer to anyone who has responsibility in capturing user requirements and translating them into instructions for programmers. This broad definition includes business analysts and application designers. Though infrastructure architects and designers play a key role in shaping up the IT environment, I will classify them as programmers in this discussion because they are often at the receiving end of something specified by someone else.

Those who have needs and ask for something to be done with the IS/IT systems are users.
Those who translate user needs into work instructions are architects.
Those who actually execute the tasks of creating or modifying IS/IT systems are programmers.
The expression write solid code designate the act of creating an artefact that can be unambiguously understood as machine code, when used in a modelling context these are formal model artefacts, when used in a programming context these are program source code.

I know there might be a million other definitions out there. I think, at this point, someone could take offence and quit reading. That would be too bad. I am not interested in definitions and titles, I want to make a point and I need these specific working definitions. They work fine in this context, take my word for it.

Let’s give a simple persona to our IS/IT Architect,  Kermit. Kermit is a man in his mid-thirties, he works for a company called Trotters Fresh Dairy Products  Ltd (known as Trotters).

Say that Kermit does not write code, whatever the reason. This means that Kermit is not familiar with coding issues because he doesn’t deal with them regularly (so Kermit actually knows a programming language? good for him, but he is not involved in coding at Trotters and that that’s the point here). Kermit only talks in concepts, not related to code.

Kermit communicates his concepts to the programmers Robert and Marie-Louise using diagrams and explanatory notes. Kermit also communicates with business stakeholders using diagrams and explanatory notes.

As software is written, there will inevitably be mismatches between the application release(s) and user expectations – malfunctions are particular kinds of mismatches, changes in user expectation are also forms of mismatches. Resolving any such issues involves representatives of users, programmers and architects. At the very least, Trotters IS/IT will be facing a number of challenges due to the combined effect of the following factors:

  • Kermit made his architecture decisions based on his extensive knowledge of widely used architecture frameworks and standards, papers from industry analysts and discussions in architecture communities, his own perception of what the business is about and what matters most to Trotters business and organisation
  • Kermit’s architecture was interpreted by the business according to their knowledge, their perception of IT and software (often shaped by external influences and people background), and their evolving needs
  • Kermit’s architecture was interpreted by the programmers according to their knowledge, the platform and programming tools they are using and the resources that were available to do the work.
  • Coding was constrained by a number of factors including technology platform, programming tools, resource availability, Robert and Marie-Louise are not aware of everything that might be possible with the tools in their possession. Some of Kermit’s suggested principles were not feasible due to these constraints, choices had to be made on-the-fly.
  • Changes constantly occur in Trotters’ business environment, with them people adjust their perceptions and their expectations, it is very hard to convey all those changes in a usable and timely manner to all stakeholders. So people make assumptions that they feel comfortable with and won’t necessarily validate such assumptions.
  • Business is always pressed for time, competition is fierce in Trotters’ industry, financial constraints are ever present, decision makers are dealing with compromises all the time

Arguably there is more to say about the factors that influence complexity in the organisation, the above seem sufficient to make the point here. Let’s analyse the impact of Kermit’s lack of awareness of the code:

  • Industry architecture best practices, analyst white papers, none of this make sense until they are cast into the reality of a specific organisation. This cannot be done efficiently without intimate knowledge of the platform and the way the application is being (or supposed to be) coded. With Kermit, Trotters organisation will be learning this reality casting process the hard way
  • Even if perfectly drafted, the architecture can quickly become stale because the business reality would have moved after Kermit issued his blueprints but before the applications could be fully built and released.
  • Kermit couldn’t coach Robert and Marie-Louise efficiently, because he wasn’t involved in the coding. Even if Kermit would work closely with the programmers, since Kermit can’t write solid code, then a significant amount of the programmers’ time would go into educating Kermit on coding issues and practices
  • The numerous micro-decisions made during the software construction contribute to a non-negligible change in the initial promises of the architecture, such changes will not surface until an application release is available to the users.
  • Kermit misses the chance of bringing any lessons learned back into his architecture vision, because the feedback loop is not present or is poorly executed. Conversely, Kermit has little or no way to ensure, thus guarantee, that his vision is actually been executed upon. If the vision wasn’t correct, that fact is not properly reflected everywhere. If the vision was correct but was poorly executed, there was nothing to prevent that from happening
  • Vendor platforms evolve, so any knowledge built on a particular set of vendor solutions is likely to become obsolete and require refreshing before it is put to use after a certain amount of time. This constant knowledge renewal typically doesn’t happen, sometimes because it cannot be afforded, but also partly because people tend to get stuck in their routines and fail to notice that their knowledge is becoming obsolete. There is nothing in place to validate that knowledge at Trotters’ is adequate and aligned between the architecture practice and the programming practice
  • Kermit probably know some technology platforms very well, but there is no telling that he knows the particular platform that is part of the solution at Trotters, or perhaps the platform has evolved since the last time that Kermit did any hands-on work on it.
  • Kermit cannot assess the experience of Robert and Marie-Louise on the platform either. Conversely, Robert and Marie-Louise have no effective way to find out about each other’s strengths and ensure they are complementary. Trotters’ organisation has to trust that things would work out somehow
  • Sometimes people do notice that their knowledge might no longer be sufficient, some could then become defensive and would fight to keep any blind-spots from the open. This is human, it can be fought but it should mostly be managed. Users, architects and programmers at Trotters are facing the same dilemmas, they might not even be aware that this could be motivating some of their actions.

We can go on and on about the factors that could be causing mismatches between user expectation and application releases, but the above is sufficient to derive a pattern and draw some preliminary conclusions.

When there is any significant distance between the architects and the actual solution building and delivery, inefficiency tends to creep in very quickly and organisations don’t get the most of their assets. It does not help when those who specify what needs to be done and outline how it should be done, are removed from the actual construction of the solution. When the architect has no idea what code was (or is being) written, he could be talking about concepts that only exist on his slides and documents but actually never materialised. What would be the point of that? The above is the rationale behind my statement that An IT Architect should write solid code.

In next settlements I will elaborate on how an architect could be writing solid code, increase his effectiveness in the organisation and ensure that his vision of the solution is as close as possible to the actual solution. I will call this Say it in Code.


I am an IS/IT Architect, I could be subject to the same shortcomings described above. This is one of the lessons that I have learned over time. I’ve always felt this to be an issue in my job, I try to minimise any gaps between the vision and the realisation that was made of it by staying close to the code.

Microsoft are all in – is this panic in the Clouds for some?

With Microsoft’s latest push to Cloud computing, the field is likely to change significantly in many ways. For developers, a mixed-blessing as they can target the Cloud but at the same time need to architect more carefully than before. For competitors, this could mean going back to the drawing board and reviewing those marketing materials. For the end-users, security could become a nigthmare fairly quickly.

I read the news today oh boy,
the Redmond giant has just joined the war.
(my bad retake on a Beatles classic, I love The Beatles)

Now that Microsoft is all in the Cloud, things are set to change in some significant ways. Like it or not, Microsoft is doing what they’ve always done: embrace a technology promise with the intention to rule it. I’ve read a few articles and blogs mocking Microsoft’s Cloud announcement, which I found to be a misguided view on the tech giant.

Few would have forgotten, there was a time when Microsoft was scorning the Internet. Eventually, they turned around and entered the web browser market, and bossed it comprehensively, wiping out Netscape’s market in the process.

Microsoft all in the Cloud, There’s something in it for everyone.

For Microsoft Competitors: is it, Panic in the Cloud yet?

At the very least, lots of people will now have to scrub their presentation slides and other flyers, positioning Cloud as an alternative to Microsoft has become a confusing message, no longer a differentiator. Regardless of how they do it, if Microsoft says that they’re in, buyers will take notice and start to ponder their position, markets will react. That is what matters the most to Microsoft’s clients and partners alike, they’re definitely avoiding the fate of WordPerfect.

For Visual Studio Developers: is it, the strongest will surf the Cloud?

Enabling Visual Studio developers to directly target Cloud platform will be a huge empowerment to lots of developers. The ability to develop and package Azure applications from within Visual Studio is going to hit the right chord for many. The bad news is that, more than ever sound architecture design will determine success and failure. The finest developers will be able to do really nice stuff, those who just click their way to a solution will probably create a lot of mess.

For Windows users: is it, the Cloud sets you free?

With Windows applications becoming first-class Cloud clients, it become possible to manage documents on the Cloud natively from Windows and Ms Office products. The notion of office application development is extended, the office becomes virtual in a way. This could be a stretch for infrastructure management, which is likely to become significantly harder and fragmented. A lot of IT managers might be scratching their heads over this prospect, strategic sourcing might become more crucial to some organisations.

Should IT managers not buy into Microsoft’s Cloud story, this could be another “Vista moment” for Microsoft. On the other hand, we know that the knowledge worker has been clamouring to be set free of work location. Cloud enablement for the masses of Windows users could actually force IT management to accelerate their Cloud adoption schedule.

Management lessons from recent headlines on Tiger Woods

I think the recent brouhaha on Tiger Woods’ private matters is a good test of leadership and management for sponsors and organisations involved with the Tiger Woods franchise. Indeed this is a good test of society’s celebrity culture and its many shortcomings.

I think the recent brouhaha on Tiger Woods’ private matters is a good test of leadership and management for sponsors and organisations involved with the Tiger Woods franchise. Indeed this is a good test of society’s celebrity culture and its many shortcomings. I was going to ignore all the noise, but I felt a short take on leadership and management lessons can be drawn from it.

Whatever might or might not have happened, the point here is that the involved managers should be asking themselves one simple question: did we hire Tiger Woods for his mastery of private affairs and gossip control, or did we hire him for his legendary golfing abilities? If the answer is the former, then by all means you have a case to sack him. If the answer is the latter, and that you’re concerned about the potential impact on your brand then clearly you haven’t done your homework.

If Tiger Woods’ brand is such an equity for a business, why aren’t such business around when Tiger’s brand comes under attack and needs support? This might not be a standard practice, but that would have been a show of good team stewardship. That’s the point I want to make here: people put up a team for a mission, but they are not around when team members need support.

So what is the management lesson take away from this saga?

Anything that contribute to your business should concern you all the time. This means that you should take care of it throughout, not simply leave things to chance and expect to milk rewards.

How does this apply to Enterprise Architecture?

It is more to do with leadership and team stewardship. When you lead a team, it is also your duty to support and protect your team members. In Enterprise Architecture endeavours, this amounts to embracing other (non-technical) stakeholders success as one’s own. If and when you do that, you increase the odds of successful outcome for everybody. If however, you only consider ensuring that there would be no flaws on your personal outputs, that might not be enough and you could be letting everybody (including yourself) down.

This will be an interesting test, we will see what happens in the end. If the big sponsors start deserting Woods because of his recent alleged personal problems, everyone could draw his/her own conclusions. I read a non-sense that Woods attacking celebrity culture was misguided as apparently they made him. I think that’s untrue. What made Tiger is his golfing prowess, many took advantage of it as they saw fit. Now some are eagerly calling for his head, I suspect because it sells their paper. No wonder some form of papers are under pressure with the advent of social media, if they can’t communicate properly then nobody would be listening. It is that simple. Like Peter Drucker put it, it’s the challenge of getting communication out of information.

Leverage the best of community and agile approaches for results

It is a good idea to leverage the best of communities and agile approaches to product development in Software Architecture practices. Last semester product releases from Microsoft are indication that they are applying these concepts, Architects should learn from that.

It seems to me that Microsoft is applying some valuable lessons from open-source and community driven software processes: get user buy-in as early as possible, deliver early and frequently incomplete or partially flawed products. People will happily participate, you would get a more accurate feel for the reception when the product finally ships. I don’t know what the pundits are saying, but to me (as a software architect and user), this strategy pays off handsomely.

Every new Microsoft product I laid my hands on over last half-year has been nicely thought out and clearly user-oriented by design. You can almost feel that product development received a lot of attention, and that is good news for the 90% of us who use Microsoft software.

I’ve started using Microsoft Office 2010 Beta on my Windows 7 box. You immediately see the impact of some of the lessons they’ve learned with the previous major release, the ribbon concept has been tweaked, the experience feels more natural yet innovative. I’ve not had to spend any time reading documentation (though that would be a mistake for a final product, reading the documentation is always for the best), I had no troubles working just like before.

Similarly, when I first learned about the early Microsoft Azure visions, I was having a strange feeling of “lipstick on a pig” treatment. After PDC2009, I saw lots of improvements and change of heart on some early ideas that seem to be, without a doubt, the result of extensive community participation.

The early concepts and beta releases of SharePoint 2010 and Office 2010 have stunned me in their clarity of vision, for the first time I’m getting excited about Microsoft’s web-based software. Having spent the best part of last decade delivering non-Microsoft solutions, albeit I’ve never lost sight of what they were doing, I am seeing a lot of good vibes coming from Redmont these days.

Another potential idea that can be read here, would be that Microsoft is directly engaging users and hence doing away with their former approach where their partners supplied the bulk of feature requirements (I’ve read a lot of Michael Cusumano and Mary Jo Foley throughout the years, any misreading would be mine).

To me, these are all signs that Microsoft’s products are improving, they are increasingly addressing unmet user needs. This would be a software delivery equivalent of a “growth business”, I buy it.

I see a parallel with the practice of software architecture, whether its Enterprise Architecture or Solution Architecture on a smaller scoped project. Software Architects can achieve much success by adopting some of the same recipes hinted at earlier, by no means a complete list:

  • don’t seek completeness on any significant topic before getting stakeholder communities fully engaged (no, they won’t think you’re daft)
  • don’t think you have all the answers (many thought leaders are saying this), actively seek and incorporate ideas from the receiving parties – they’d have a hard-time to reject their own input, wouldn’t they?
  • delegate major chunks to smaller and dedicated groups, see to it that the inter-group communication is fluid and sustained (I don’t know if Microsoft does this, it seems many of their products are still large silos).

With this type of approach, the outcome tend to feel much more natural and the acceptance will probably be easier. You see it for example when, using the product, you guess how something might work and could verify that the feature was implemented almost exactly as you guessed. This happens a lot when I use Apple products. I used to think that Microsoft would never be able to match such feat, but I now see that they are changing their approach for the better.

Architect Vendor or Platform independence with care

Vendor independence or Platform independence should be carefully considered, weighted against the organisation strategy. Vendor and/or Platform Independence often won’t make sense if architecture is to deliver true value efficiently.

When designing Software Architecture, it is easy to confuse Vendor independence with Platform independence, or think that it is absolutely necessary. If your organisation already has a strategic platform, or that it has strategic alliance with a particular vendor, then this should be core to your architecture design processes. Ignoring this aspect, you might design a perfect solution for a non-existent problem. This is the software architecture equivalent to overcapacity, it could be costly.

There is always a temptation to come up with an architecture that is pure, scalable, flexible, and so on. But to what end? As we know, beauty is in the eyes of the beholder, and beauty for its own sake will often not make business sense. Why pursue it then?

One of the benefits of the software architecture practice is in delaying implementation decisions until after the business issues have been properly understood and captured, in fact it should be separating implementation decisions (and not delaying). But that thinking amounts to assuming that implementation is not a business concern at all, which could be wrong. There is a risk of designing a perfect architecture that simply cannot be implemented without significant performance or delivery penalty.

My point can be summarised as follows:

  • A perfectly valid process can yield perfect disasters when it is short sighted in any significant way.
  • Business domain semantics should be analysed in context, not based on a theoretical ground far remote from the specific business reality.
  • Consider the complete lifecycle of the solution being designed: if the vendor or platform lifecyle is likely to survive your solution, duly include such vendor or platform considerations in your key drivers.

In large enterprise architecture endeavours, usually there are sufficient resources to tackle all aspects of an Enterprise Architecture requirements. This is often not the case for SMEs and start-ups, the largest group operating with tight resource constraints.

It might be tempting or even self gratifying to think that you’re designing a vendor or platform independent solution, but that might not be the best way to deliver value to your stakeholders. In practice, it is always better to take sides when designing business technology solutions. This is the main reason that large businesses often enter strategic alliance with a prominent vendor and thus commit to its solutions and products. There is nothing wrong with such practices, obviously. Carefully managing the vendor relationship is another issue altogether, which cannot be discussed in this post. What could always be counter-productive however, is when software architecture practitioners would try to downplay the role of such strategic vendor products and solutions at the design stage.

The iPhone as a platform can only now follow the rest, and fast.

The environment that allowed the iPod to flourish as it did is very different from the one the iPhone was born in. In both cases Apple’s vision and ability to execute were masterful, but what also helped a lot is that the industry by and large mocked and dismissed Apple’s move until its success was well established.

Having learned some lessons from the iPod experience, when the iPhone came along to the acclaim we all know, competition took good note and immediately sprang into action. With the iPod, Apple was able to wait for the platform to mature and was virtually free to decide on the next course of action. With the iPhone, competition is already catching up fast, so it’s a level playing field this time and that calls for another strategy. It seems that no single vendor will be able to totally control the smartphone market (or whatever you call that thing that can do it all: a phone, an internet device, a media player, a media recorder, etc).

Either Apple is content to see the iPhone live in a niche market (why not?), or they’d have to take a few actions such as:

  • make the development platform available on Windows and Linux (to broaden the reach), just like they did with the iTunes client
  • develop support for another language such as Python or Ruby (they really don’t like Java, don’t think C# would be accepted either)
  • spend some of that iFund in nurtuting a business partner ecosystem

If I were starting today with developing applications for smartphone app stores I’d be very cautious indeed. Nokia seems to be bullish, not too concerned about ruffling some feathers in the process perhaps. Palm’s WebOS is an interesting attempt, though I wonder why they didn’t join forces with Nokia. Windows Mobile and Android will probably keep their ecosystems. I have yet to fully explore these other development environments, but that’s also the point: why would I take the trouble if I can’t be sure it would be worth the trouble?

As a developer, learning a new platform is an expensive undertaking and I would want to ensure I get the quickest returns and the broadest reach. In this respect Apple’s tool chain is superb and possibly leads the pack for the foreseeable future. And maybe that’s what they’re betting on. But Xcode is not available on Windows or Linux, forcing all developers to also migrate to the Mac makes it an expensive proposition for applications that probably only sell a few dollars apiece. Not every app will pull the trick of iFart or iAmRich.

It’s wait and see. In the mean time I would save my precious crisis-era dollars in web apps that can serve all platforms. For native mobile apps I would also invest in iPhone App, Windows Mobile and Android. Amazon’s Kindle being released in Apple’s AppStore is perhaps a good example that the established platforms deserve some respect in these early days.