Build (Several) Networks: According to the parachute book, 80% of all available jobs never get advertised – they are given to people who know (of) the person who needs to employ a person. If I look back at my own list of jobs, then the percentage seems to fit pretty well. Once you get the job, it’s often about knowing the right people to help you solve a problem, answer a question or to find the right people. And to be part of these social networks, you’ll need to pay attention to your reputation, ‘brand’ and ‘mindshare‘. One of the best ways to do that is to be helpful.

Be Helpful: The trick to unlocking the value of your network is to return the favour. If you have helped someone then they are probably more likely to help you – and even if you haven’t helped them, they are more likely to help you if you are known as ‘a helpful person’. But being helpful only works if you are also seen as reliable.

Be Reliable: You cannot help everyone, and if you do help, then be sure that people can rely on your help. And be sure that it doesn’t affect your ability to perform your normal duties. Getting a reputation for being unreliable can be a real career killer. And remember, you can only be reliably helpful if you continue to build recyclable skills.

Build Recyclable Skills: No, I don’t mean ‘green’ skills or the ability to sort the rubbish at home. Recycable skills are those that can be applied in different contexts, different problem scenarios and, most importantly, they don’t have an expiry date. I’ve seen people trying to become the ‘go to’ guy, and be generally helpful, through their technical skills. However, if these skills are tied to a specific technology or even worse, a specific version, then the value will expire. They are hard to transfer to other technologies. A better strategy is to use those technical skills to develop mentoring, training or root cause analysis skills – or good, general design skills. People appreciate help with, say, technology problems, but they’d love you for teaching them how to solve them without your direct help. It also helps you helping more people, as you don’t need to help the same people over and over again.

And remember: Your career is YOUR responsibility – no one else….

If you have more suggestions then please add them in the comments section – thanks!

1. Know your stakeholders: Although fairly obvious, it can be a very challenging activity, but without, it possess a real risk to your project. And knowing your stakeholder is fundamentally a question of knowing the social network of your client – a daunting task if you are new to the organisation or if the organisation is large. We all know the traditional approach of asking our project sponsor, organising planning workshops, and compare our list with other stakeholder lists. A very interesting new take on this challenge came as part of Soo Ling Lim’s Ph.D. research. Her basic idea was to apply crowdsourcing to stakeholder identification creating a snowball like process. You can try her very clever tool at Stakesource.
2. Keep it simple: A universal design principle, but it is spelled KIS, not KISS. Why? Probably for the sake of correct spelling, people have included ‘stupid’, ‘short’ or ‘straightforward’ as part of the acronym. But there is nothing stupid, short or straightforward about creating simple software that is truly useful – otherwise using software would probably be as easy as driving a car. Whether software is ‘simple’ and ‘useful’ comes down to a question of perception, so we are back to the first point.
3. Know how to deal with uncertainty: Developing software is a complex undertaking with at least some degree of uncertainty, and you or your team cannot know everything. Uncertainty can be a lack of knowledge about requirements, the utilised technologies, or the environment. This can typically be addressed either through specific analysis activities or through sourcing of additional expertise. Uncertainty also creates risks for which you’ll need a risk mitigation plan.
4. Evaluate your architecture: Unlike code, you cannot test your architecture the same way you can test code, but there are a number of good ways to continuously evaluate your architecture:
   • Present your architecture to your stakeholders while being mindful of their individual concerns – you need to know about ‘architectural views’. If they don’t understand it then it is not going to work. And when they do understand, they’ll have the opportunity to provide feedback enabling you to explain and test your design rationale.
   • Use general peer and specialist reviews.
   • You might want to conduct a proof of concept or pilot phase, although far from mandatory. A PoC can be a good way to evaluate specific and important parts of the architecture using prototypes, but be mindful of the PoC anti-patterns: The mini-project, fuzzy questions or success factors, and a loose scope. If you are going to re-use prototype artifacts then be sure you know what quality trade-offs were made in order to meet the (short) PoC time frame. And even well developed code can be useless, if the architecture of the prototype is inappropriate. In other words, know your ‘technical debt‘.
5. You: The role of an architect is a leadership role with its own KIT:
   • Kompetence: Be competent by showing your stakeholders a well referenced, well argumented, and traceable rationale for your architecture.
   • Integrity: Be the best advocate for the concerns of your stakeholders – if you believe they are wrong then its your job to convince them otherwise.
   • Trustworthy: Backup your words with action, and always be available to answer questions and provide guidance.

I’m sure there are other critical and useful skills – feel free to list yours

As Wright points out, technical skills are important, but if you cannot convince people to collaborate and follow your ‘architectural vision’ then those skills really aren’t to much use. Your skills as an architect needs to go ‘beyond the tools of the trade‘ including knowing how to ‘visualise your architecture‘ and be prepared to have the ‘software is not a building‘ conversation. Wright also provides a useful list of SWOT and cause-’n'-effect analysis techniques.

If you are in a reading mood then I’d suggest reading some of my previous blog posts – all related to this topic:

• Does architecture emerge or is it planned?
• More isn’t just more…
• Architecture Reviews, Technical Debt, and the Cloud
• Enterprise Interoperability

Although security has repeatedly been highlighted as one of the key concerns with Cloud Computing, only 20 percent of cloud vendors see security as a competitive advantage, and fewer than 27 percent feel their cloud services can protect and secure customer information.

Why is there such a gap?

Technology maturity might be part of the picture, but after watching Bruce Schneier’s TED talk, The security mirage, it strikes me that something much more fundamental is at play here.

Bruce Schneier at CFP 2007: Open panel on Net Freedom. (Photo credit: Wikipedia)

In the talk, Bruce introduces three elements to explain the concept of security (illustrated above). He defines the real security (risk) as a trade-off between our willingness to invest effort and resources to mitigate the risk (e.g., buying insurance or avoid people with the flu) versus the perceived likelihood of the bad stuff occurring. In other words, our assessment approach is primarily an emotional one according to Schneider.

And while our emotional security assessments are generally well aligned with the real risk (we happily live in houses full of electricity), we do need two things: 1) Ability to visualise the risk, and 2) familiarity with the event occurring. For example, we need the model of bacteria to rationalise the risk of flu infections, while the media coverage of the swine flu distorted our familiarity with a particular flu strain.

The problem for Cloud customers is that cloud security is hard to visualise and the general familiarity remain low or distorted by the media coverage of events such the recent security breaches at Sony. Customer’s feeling is probably not a good perception of the actual cloud security. Similarly, because cloud vendors work with their technology everyday, they are familiar with the risks and are able to visualise them with relative ease (in comparison with their customers). They have developed a model of how to rationalise the security risk and therefore make better predictions.

However, if cloud vendors don’t (as the survey indicates) see security as a shared responsibility – and maybe just as a matter of ‘turning on the various encryption features’, then they are likely to fail to help their customers develop appropriate models of cloud security – and cloud security is too complex to leave it to our feelings. This could result in either customers not signing up because they are ‘too scared’ (not willing to go into a house full of electricity) or they sign up unaware of the risk they have taken (e.g., refitting a power adapter while the electricity is on).

Corporate technology customers already have models of security covering areas such as trust, governance, policies, audits, training, reporting, certification and (some) technology – so the effort on the cloud vendors part should ‘only’ be a matter of adjusting existing models to the new Cloud environment than starting from scratch – but if they don’t engage with their (potential) customers, security will remain as one of the main obstacles to cloud adoption – simply because customers cannot be sure that their security trade-offs strategy align with the Cloud vendor strategy. And just turning encryption on does not address the problem…

The report:
http://www.ca.com/~/media/Files/IndustryResearch/security-of-cloud-computing-providers-final-april-2011.pdf

Media Coverage:
http://www.darkreading.com/cloud-security/167901092/security/security-management/229402544/users-service-providers-at-odds-over-cloud-security-study-says.html or http://www.infosecurity-us.com/view/17688/security-is-left-behind-in-rush-to-cloud-survey-finds/

Concerns about ability to lock down the hypervisor:
http://www.pitchengine.com/organisations-virtual-environments-at-risk-from-inadequate-security-management-new-independent-study-commissioned-by-ca-technologies-reveals/105001/

Image via Wikipedia

According to a recent survey by MIT Sloan Management Review, 60% of employees surveyed don’t have enough data to do their jobs. And it is not a technology challenge; but rather cultural and management. Not an entirely encouraging statistics in the context of the growing importance of the tertiary sector of our economies – information is key, especially if you work within the IT industry.

The survey reminded me about Nonaka, a professor in management research. According to him, we have two kinds of knowledge – explicit and tacit; and four knowledge processes (framed below in the context of software architecture):

• From Tacit to Tacit – when a less experienced architect (or wannabe architect) observes a master architect in action; if your organisation has a shortage of good architects, then this one is important.
• From Explicit to Explicit – an individual can combine separate pieces of information into a new whole, e.g., combining several architectural styles and patterns into a new, solution specific architecture. But explicit descriptions are only as good as people’s ability to read and understand them – i.e., the tacit knowledge the reader is assumed to possess.
• From Tacit to Explicit – when specialists are able to articulate more of what they know, e.g., capture and describe unique reference architecture or new patterns. Do you or your organisation really knowledge how well the architecture is working for each system and project?
• From Explicit to Tacit – i.e., you learn by doing. You can only learn so much by reading, and the next step is always applying the acquired knowledge in practice. Are your architects following the templates, styles, references, patterns; or are they just making it up from scratch?

The key is the tacit knowledge, that people need in order to perform the four processes well – and mentoring people in how to do them is central to any organisation’s ability to `empower’ (another good management word) their employees. And as an architect, it is important to step back from the daily activities, and consider what you are doing as part of the four knowledge processes. Your architecture is only as good as the available mentoring…

References
Nonaka I, 1991, ‘The knowledge creating company’, Harvard Business Review, Nov-Dec, pp. 96-104.
Nina Kruschwitz and Rebecca Shockley, 2011, ‘First Look: The Second Annual New Intelligent Enterprise Survey‘, MIT Sloan Management Review.

The red dots are the tracker sites (confirmed by privacychoice.org). The two separate dots are mozilla.com (grey) sending information to webtrendsline.com (red), while wordpress.com sends information to wp.com, youtube.com, gravatar.com and quantserve.com (red) (top right five dots)

The big one, which surprised me, created by visiting arstechnica.com, amazon.com and cnn.com – only three sites – and another 27 companies know about my web browsing! Most of whom I have never heard about. For example, loading an arstechnica.com webpage will send your browsing information to Twitter, Facebook, scorecardresearch, outbrain.com, 2mdm.net, addtoany.com, reddit.com, doubleclick.net, and Google.

And sites like scorecardresearch, facebook and doubleclick (owned by Google) collects from other sites.  Basically, they are likely to know more about you than any government organisation and maybe even your friends.

Paranoid yet?

I occasionally read Nick Malik‘s blog, Inside Architecture, and his latest post about ‘Business Capability’ reminded me of IT people’s general ability to take a perfectly understandable word, such as capability, and turn it into something confusing. This is not a criticism of Nick or Paul Harmon who wrote the article, Capabilities and Processes, that promoted Nick to write – but merely used as an example to illustrate my point.

Now, IT’s definition of ‘Business Capability’ is ‘what a business does at its core‘, and its description (e.g., model) captures ‘what the business does (or needs to do) in order to fulfil its objectives and responsibilities‘. The idea is to focus on ‘what‘ an organisation needs to do, rather than the actual ‘how‘. A conceptual view, if you like. And so the discussion continues in search of the ‘what’ and what it really is.

I think the confusion around ‘Business Capability’ stems from the fact, that a noun can refer to an entity, a quality, a state, an action, or a concept. The above definition uses capability (the noun) in the meaning of an action, entity or concept, whereas ‘capability’ in its literal definition is a noun in the sense of a quality. Webster defines ‘capability’, as ‘the quality or state of being capable‘‘ – i.e., the degree to which an organisation is able to perform the ‘what’ rather than the ‘what’.

Within the management (rather than IT) literature, we find, that Grant (2002, p. 145) uses the term ‘capabilities’ in reference to an organisation’s capacity to undertake a particular activity. Similarly, Hanson (2002, p. 20) views organisational ‘capabilities’, as the capacity to deploy resources integrated to achieve a desired end state. In other words, a capability is a qualitative measure of an organisation’s skill and abilities, rather than what an organisation does – which is why they are often difficult to imitate. For example, Apple‘s capabilities in designing a new tablet are hard to imitate as evident by the poor reception of competing Android based tablets. Although the competing organisations know the required design activities (the conceptual view of ‘what’), their capacity to perform those activities are less than Apple’s.

No wonder people get confused.

References

Grant RM, 2002, Contemporary Strategy Analysis: Concepts Techniques and Applications, 4th edn, Blackwell, Oxford.
Hanson D, Dowling P, Hitt M & Ireland RD, 2002, Strategic Management: Competitiveness and Globalisation, Pacific Rim edn, Nelson, Melbourne, pp. 85-115.

Google has always been about getting the job done, and I think Google’s interpretation of a social networking site is about productivity and collaboration (one of the key features of Google Docs). In contrast, Facebook is mainly about keeping up with your ‘friends’ and playing a game or two – a virtual version of playing the games console at home while chatting with your friends (and watching a bunch of ads). Google’s strength in the social networking market will be their ability to turn the social networking experience into a useful experience for yourself and your friends; rather than being a time waster.

The more offerings Google is able to integrate; the bigger the differentiator to someone like Facebook. People isn’t going to leave Facebook, because Google+ is social feature by social feature better than Facebook. They’ll move to Google+, because they’ll find all of Google’s offerings in one place – and having your ‘friends’ in that same place will be handy for doing more than just chatting and play a game or two. Like organising a trip using Google Docs, Maps and Calendar in the hangout area, or reviewing tomorrows presentation with work colleagues. Or go virtual shopping together using Sparks and Shopping. Now add the Google Apps Marketplace and Android, and the sky’s the limit.

Google+ is really about you and your friends + Google; rather than just Google+.