As stated previously in this blog, software architects must be innovators. They are responsible for creating a technical vision to apply new technologies to further the customers’ goals and/or reduce development costs and for high level designs. Many books, lectures, blogs and so on describe the process of innovation and are not repeated here but, when confronted with a problem, most developers and architects either work out their own solution or lazily Google something similar. However, software developers and architects, in particular, need not “reinvent the wheel”.
Ignoring structured learning, such as degrees and certificates, there are two ways architects can learn ways others do things. The first is to proactively listen for new information.Most software architects will already read favourite blogs or web sites, follow twitter luminaries, subscribe to magazines, read textbooks, attend conventions and so on. However, the key with information sources is efficiency – five sources providing predominantly relevant information is better than one hundred poor sources.
Aim for a mix of information sources, including some technical, some design, some industry commentary and some aggregators (those that provide interesting links to other sources that may only occasionally have relevant information). Review sources over time because the architect’s requirements, knowledge and expectations will change over time. Experiment with new things and plan to either remove “old favorites” or check them less often when they are no longer being consistently useful.
The second is to research topics when the need arises. Competitor’s products are good places to start but, unless this is a major feature, information is often sparse. Internet searches or dedicated development sites are useful but iterating synonyms is time-consuming.
Software architects often neglect academic texts or papers, which are particularly useful if the group is using more complex algorithms. Use Google Scholar or consider joining ACM or IEEE to access their academic paper repositories. Such papers may be dry or assume too much knowledge initially but persisting may reveal better approaches, establish common terminology and point out less explored areas suitable for potential patents or the architect’s own academic papers if he or she is so inclined.
Some would recommend looking at open source software. Assuming the product is chosen with care, open source software or other people’s code in general is a great source of information from obscure language features to new algorithms. However, the software architect must not copy any code verbatim or infringe patents or licenses.
If the problem is not solved or not solved sufficiently by prior art and the organization has a process in place, software architects should create and file patents. Arguments over whether software patents encourage or discourage innovation are irrelevant. As they say, “You cannot win the game from the sideline”. The IT industry is pursuing patents aggressively and companies that do not, such as Google with Android, now face legal challenges and hurdles. For the software architects, patents are one of the few peer-reviewed, universally available measures of creativity available. Many organizations also offer financial incentives for them, too.
Beyond the software architect’s products and patents, avenues for innovation include open source software, apps in app stores, writing a technical blog, conferences or academic papers. Approval may be required from the organization and social networking activity will need to comply with the organization’s policy but this can help the software architect’s personal brand and help find or precipitate conversations with like-minded individuals.
The single most important thing about innovation is to start. A software architect must be a technical leader but cannot lead without producing and cannot produce without starting. The first attempts may be unremarkable or unsuccessful but persistence will bear fruit.
Like this:
Like Loading...
Anthony Langsworth
@alangsworth
anthonylangsworth
Random Acts of Architecture 
Can you give any examples of the sources you are currently using?
Given that I am currently working on information security using Microsoft technologies, I follow: