Two sides of same coin.
The role of architecture, albeit neither overtly tangible nor receives attention grabbing headlines, plays a critical role in the predictable daily operations and deliverance of committed services to customers. Those two attributes are more strategic than tactical. Predictability is a proxy for risk management, the ability to respond swiftly at a time of misfortune. Deliverance is a measure of dependability, trust, and branding that translates into leverage in negotiations, which in turn becomes a decisive factor when choosing a partner among equals. Good IT system architecture makes the critical difference between:
a) an enterprise's strategic advantage and an Achilles' heel
c) near-zero technical debt and a do-over
In the field of architecture, there are 2 complementary and contradicting concerns: Purity and Pragmatism. As always, there are proponents and detractors on both side of the aisle. Purists weigh interoperability of disparate building blocks, mutual co-existence, development and deployment simplicity, and low/optimal operational costs as uncompromising principles when developing architectural blue prints. Pragmatists weigh creating competitive moat through technical superiority, protecting intellectual properties with patents, and finessing the licensing model to maximize profitability when developing arch models. Understanding what the right mix of the two concerns helps make short and long term decisions that are both strategic and tactical.
How would it look without them?
An infrastructure engineer can easily read the specs, order, and assemble a bunch of pizza box-like server units from a myriad of brand name local vendors or white label vendors in Asia. They then download a personally delectable flavor of OS from an open source mirror or a professional services vendor and install them on top of the pizza boxes. Finally, they choose a run-of-the-mill web and app server combo from a traditional/reputed shop or chose a combo from state of the art neo noir style frameworks from an intrepid, iconoclast developer/group and configure them to their heart's content and put them into production—without architects.
A self-proclaimed network engineer orders run-of-the-mill network switches, routers, HBA, and cables from the Sears-style catalogue (even I've ordered from a 600+ page catalogue), creates a DMZ layer with iron-clad firewalls to thwart hackers, and configures authentication and authorization layers so that only the clan can get in - without architects.
In the same way, a database engineer follows instructions in the installation wiki and FAQ's of a traditional SQL or NoSQL Server product from a reputed vendor or picks one of many open source flavors, installs, and configures into the boxes the infrastructure engineer has built for them and turn them on in production—without architects.
A group of nocturnal application developers can write a bunch of cool applications and put them into production—without architects.
Voila, your entire IT system is now up and running. Currently, thousands of production servers run in enterprise data centers—without architects. It is not atypical that a bunch self-styled, innovative, young, and ambitious professionals make critical decisions on how to build servers, create databases, write applications, and operate the entire system.
Where is the Breaking point?
The ad-hoc IT infrastructure buildout, somewhat mercurial application development, and deployment and maintenance process will of course work, but it will only take you so far. Without incorporating pragmatic architectural considerations in the buildout, development, and operating model we know things break down at some point.
If history is any guide, the breaking point is always scale, performance, and the 99.999999% availability of the IT system for a 24/7 business model. Scale and performance are indicators of sustained business growth, and the 99.999999% availability is an indicator of brand, trust, and service commitment to customers.
If you need an example, look no further than the initial web application developed by Pierre Morad Omidyar, a software developer by trade and founder of eBay. Omidyar began to write the original computer code for an online venue to enable the listing of direct person-to-person auctions for collectable items. He created a simple prototype on his personal web page and on Labor Day in 1995 he launched an online service called Auction Web, which would eventually become the auction site eBay. The service was hosted on a website Omidyar had originally created for information on the Ebola virus.
Another example is the initial web application developed by Mark Zuckerberg, founder and software developer at Facebook, in his dorm room. There are several examples like this if you scour the web.
In both cases, the initial development and operating model - without incorporating established architectural considerations – of the IT system did not last long due to scale and performance shortcomings when their web based business applications experienced sudden and exponential growth.
Where the rubber meets the road
The complexity of technological choices and integration challenges that come along with them demands skill and experience in how to stitch together and tune different building blocks into the right set of useful/consumable products and services. Physical Infrastructure (H/W), data (DB's), application development platforms (middleware, frameworks), applications (CRM, HR, ERP, custom apps, etc.) and an array of deployment and operational tool sets are 4 critical components of any IT company to keep the revenue generating engine humming and running. Integration of infrastructure, application development, and database management tools require the skills and leadership beyond those of engineers and developers.
Architects:
- Give physical shapes to concepts that have business value
- Provide the blueprint
- Compile the tool list and building blocks so that IT professionals and/or system engineers can build the infrastructure, and database folks can start constructing the data models, their ownership, and the intricate relationship between them
- Specify details to the developers or software engineers so that they can focus on coding the applications
- Guide the development of operating manual/standard operating procedures so that operational folks can start their long journey of learning how to "drive" the system on a day to day basis
Thanks,
Shak Kathirvel, Application Architect
No comments:
Post a Comment