Recently I stumbled upon a great article written by Rockford Lhotka, a recognized and published expert and developer of the CSLA.NET (Component-based Scalable Logical Architecture) framework. This article got me thinking quite a bit and I would like to share my thoughts.
In the article “Does .NET Have A Future?” (Please go read it, it’s excellent!) Rockford goes on to ask and provide his opinion on the question:
Does .NET Have A Future?
This is a great question and one I think most .NET professionals have on their minds. I see myself as a perfect example of a .NET professional who at one point asked this very same question.
Today I received an email that states:
Don’t miss your chance to win a 2013 Aston Martin V8 Vantage. Deploy a Virtual Machine or a Web Site using your MSDN Windows Azure benefit by September 30, 2013.
I was shocked to read that they are giving away an Aston Martin! I wouldn’t mind if this becomes the norm type of prize for trying out providers but this wreaks of desperation.
I personally have a bad taste in my mouth after having tried Azure. Could this be their attempt at recapturing a small percentage of those who gave Azure a try and only walked away feeling disappointment?
What exactly is a software architect anyway?
Software development, relatively speaking, is an incredibly young craft. Additionally, the role of an architect within a software development organization is a very fluid one (same goes for CTO). I believe it is important to understand how an architect fits in the software development environment, both within the engineering and the business organisations, before we can discuss how to become one!
Requirement #1 – Experience and exposure
Let’s image we are equating software development to rope making. The following chart will express the equivalent experience level expected in each of the different position:
|jr developer||learns about rope|
|developer||can tie basic knots|
|senior developer||calculates rope strength and knows a lot about knots|
|architect||knows more about rope than you ever will|
|senior architect||invented nylon|
Managerial styles is a very subjective topic. It is subjective to an organisations hierarchical structure, its size, its role, and the manager’s role in the ecosystem. For this post, I would like to talk about effective managers, their attributes, regardless of the organisation. The single attribute we want to carry forward is that a managers responsibility is to maximize the performance of the organisation.
In order to make the post easier to digest, I will tailor some of the examples to a topic most of my readers can identify with; a software development manager in a product delivery organisation.
One of the questions I get asked most often, from both industry experts and otherwise, is what my strategy is for keeping up with technology. While there are industry professionals who are experts in this matter and can help with creating checklist style approaches, the following is derived from my experience.
As most modern-day software professionals, my fascination and passion for technology started at an early age. Early enough where I had the opportunity to make software development, logical thinking, and the art of continually searching for and acquiring knowledge a part of my personality. I grew up tinkering with computers, learning how to code, and scratching my forehead trying to wrap my immature brain around the concepts of object-oriented programming, router ip tables, matrix manipulation, and other fun technology related topics. I can first handedly attest to the difficulty this poses for a brain who has yet to be introduced to the !
Yes, abstraction, polymorphism, inheritance, and other fancy words that describe the beautiful world of object-oriented software development sounds scary to those who are unfamiliar with them, but as you slowly delve into these concepts, a true, honest, and remarkable world emerges. In this world, things are black and white, 0’s and 1’s. Things either are, or aren’t. Using incredibly simple building blocks, things such as Facebook, stock exchange trading platforms, and even aircraft auto pilots have been forged.
As you can tell from my digression (something I can’t help but indulge in when on this topic), my expertise is really derived from passion, which is my key focus for this post. I am making passion a mandatory trait to even begin discussing keeping up with technology.
Lean/Agile software development methodologies such as scrum are not only the new fad for achieving hyper-productivity in modern software development, they are becoming the norm. Shifting the life-cycle of software development from the sequential design processes (e.g. waterfall) to agile promises big gains in efficiency and overall output but usually bring in a feeling of loss of control over long term initiatives such as architecture. The gains agile deliver are usually attributed to the shorter delivery cycles which promotes fail fast (fail sooner rather than later to minimize impact of failure), an opportunity to re-shift product delivery focus with minimal consequences, and promotion of individual dynamics.
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
As we can deduce from the manifesto above, agile is about doing things quickly and adapting rapidly. Looking at traditional architecture, a process which plans out infrastructure, components, interactions, etc…, sometimes considerably in advance of actual development, you will probably realize that there is a serious incompatibility between the two approaches.
Architecture is all about quality. Architecture focuses on aligning the technology with the business’ needs and goals. This alignment usually deals with incredibly large swaths of components at the same time due to very interdependent nature of technology and processes. It is not uncommon for an organizations architecture road-map to span many years, usually due to the size of the projects, the number of delivery teams involved in the implementation of the initiatives, and the lifespan of technological components.
As an adamant believer in the imperative need of strong leadership in technical organizations and how these roles contribute towards an organization’s success (and in an effort to mold myself to optimally fit such a position) I am constantly on the lookout for views, opinions, research and articles regarding the topic. I recently discovered an excellent piece on the CTO (Chief Technology Officer), an executive function that is relatively new to the business world, by Tom Berray of Cabot Consultants, Inc.
If you ask most people to identify the duties of most c-level executives, they will probably easily identify the CEO, COO, and CFO function and their respective duties. Pose the same question regarding the CTO position and you will probably get a mixed bag of answers. This might be due to the immaturity and lack of pervasiveness of the role in gneral, or it might be due to one’s lack of understanding of how technology plays a key role at the top of the chain in modern businesses. Nevertheless, it is important to understand how this influential and maturing function is becoming a critical role in any organization, along with what types of candidates will most successfully fill this role.
The CTO function’s role in an organization is directly tied to the organization’s needs, size, maturity, industry, and roster. In this blog we will analyze the CTO role as 4 distinct models: Infrastructure Manager, Big Thinker, Technology Visionary and Operations Manager, External-facing Technologist.
On July 31st Microsoft started rolling out Outlook.com, their new Windows 8 themed web based email service slated to replace msn.com, hotmail.com, and live.com email accounts. In their own words, they promise to:
Microsoft today introduced Outlook.com, a new personal email service that reimagines the way that people use email – from a cleaner look, to fewer and less obtrusive ads, to new connections to social media sites like Facebook and Twitter.
As seen in some articles such as this one, many users have been rather frustrated with Microsoft’s roll-out of this new service. The concerns seem to range from auto-upgrade without asking for permission, to loss of emails.
While these are serious concerns, I have been experiencing incredibly flaky service with the new system, which to me, points to stability issues. I frequently have to refresh my web page about 5 times until I can view my emails and even then, I can only view one or two emails before I am booted out due to a system error, my Facebook and twitter feeds don’t show up, my read emails still show up as unread, my deleted emails magically resurface, and much more!
The true value of a software Architect in an organization is the ability to translate the business’ vision and strategy into effective enterprise change, usually starting with the solution architecture. This means that an Architect needs to truly understand the business drivers and how they lead to features at the product level in order to successfully guide a product’s architecture road-map. Inversely, an Architect should be able to communicate both the technical and business aspects of this strategy to any audience, technical or otherwise.
The communication style used to deliver the message to distinct groups varies widely based on the audience’s duties. Technical folks focus on the technological implications of the architecture strategy and are usually more interested in the how rather than the why. If you take a group of developers they would rather know how their specific areas of concern are affected and what they need to focus on.