I read an article recently that made me think about Moore’s law. According to Moore’s law, roughly, the number of transistors that can be packed into a small piece of silicon will double every 18 months. We’re currently edging on transistors as small as 10nm, which will be a magnificent achievement. Whether we’ll be able to keep up with this pace of miniaturization is yet to be seen. I recall the debate from the 2000’s about whether we would be able to breach the 25nm barrier. Clearly, we got past that obstacle, perhaps we can get past the 10nm threshold as well.
The latest innovations in computing have pushed the envelope on computer processing: the proliferation of mobile devices, IoT, cloud computing, big data, etc. It seems to me that, even with the continued advancement in processing power, our processing capabilities pushing ahead at the pace of Moore’s law could actually be exceeded by the mountains of data that need to be processed. In the case of mobile applications, bursty data connections over mobile networks prevent apps from operating a peak efficiency (Golden, 2010). Thankfully, there are smart folks out there who figured out how to harness the power of unused or under-utilized resources that can help to make up for the inherent limitations of working on a mobile platform.
Memcached is just such a technology. It’s conceptually simple, and implementation appears to be relatively headache-averse. It is a method of pooling unused memory. In any given cluster of servers, each server has its own memory cache. Under normal circumstances each cache is a distinct, limited instance. However, when Memcached is deployed on a cluster, the cache of each machine is pooled into a single cache, shared amongst each server (Dormando, 2009). The advantage of this is that the utilization of Memcached can improve application performance by storing data locally that might otherwise have to be retrieved/stored by means of slower channels (e.g. Web services, databases, etc.).
Another innovation of Memcached technology is the way in which the cache is handled. It uses a “Lease Recently Used” paradigm in which releases data that doesn’t get used over some specified timeframe (Dormando, 2016). This eliminates the need for Java-like garbage collection and keeps the cache from getting bloated with superfluous data. These features are particularly useful for mobile, as mentioned, but also to address the challenges posed by the application architectures needed to support the challenges of cloud computing and big data.
Dormando. (2009, April 3). Retrieved September 9, 2017, from http://memcached.org/about
Dormando (2016, May 27). Memcached Overview. Retrieved September 7, 2017, from http://memcached.org/about
Golden, B. (2010, January 19). Cloud Computing: The Future of IT Application Architectures. Retrieved September 9, 2017, from https://www.cio.com/article/2421325/virtualization/cloud-computing–the-future-of-it-application-architectures.html
Post 2 – Application Integration: Cost Increases Associated with Mobile Computing
Like any other business cost-center manager, CIO’s are driven to reduce costs rather than seek to spend more. It take a brave CIO, indeed, to push for additional spending. However, with the proliferation of mobile devices, cloud computing, the integrated nature of enterprise computing, IoT and associated big data – it may not be possible to keep up with business computing demands and also save money.
There are several reasons for this. First, supporting mobile devices simply costs more. Quite a lot of work goes into the development of mobile applications. Specialized skills and tools are required to support it including the management of mobile users, server-side logic implementation, UX development, data requirements and data handling (see my earlier post about Memcached), and even specialized testing efforts (Tarcomnicu, 2017). As a QA Analyst I know all too well about the challenges, time and expense of assuring that mobile applications work correctly across platforms, after OS updates, and on various mobile browsers (feel free to take a peek at my LinkedIn profile). Moreover, enterprise mobile apps will likely need to access data from legacy enterprise apps – and to be able to operate without significantly draining battery life in the process (Altman, et. al, 2012). All of these considerations add to the cost of mobile application development.
There are a number of upsides that CIO’s can use to sell this increase in investment (Tarcomnicu, 2017):
- Greater accessibility
- Improved customer engagement
- Reinforce brand recognition
- Improved value propositions
- Additional sales channel
Interestingly, there are mobile platform-based cost factors for CIO’s to consider as well. Android applications tend to cost 2-3 times more than iOS apps, and iOS apps tend to serve as a bellwether for application success (Tarcomnicu, 2017). This might be the case because iOS is the older, and perhaps more stable platform between the two, with a significantly larger and more robust app store as compared to Android’s app store. It might also be the case that the development tools are more mature as well, leading to quicker development times and lower costs.
Altman, R., Pezzini, M., Sholler, D., Thompson, J., Gall, N., & Wilson, N. (2012). Predicts 2013: Enterprise Application Architecture Will Emulate Big Web Sites. Gartner Database. Retrieved September 10, 2017. Document ID: G00245997
Tarcomnicu, F. (2017, February 20). The Real Costs of Building a Mobile App for iOS and Android. Retrieved September 7, 2017, from https://www.entrepreneur.com/article/288027
Post 3 – Application Architecture Roles
If ever I mention that I’m studying Enterprise Architecture, I am invariable asked, “What is Enterprise Architecture”. I must admit, for those first few months after joining the EA program at PSU, I struggled to come up with a concise definition. I’ve found some value in describing in terms that are more easily assimilable – at least for IT folks. My approach is to describe EA as an amalgam of business architecture, application architecture, data architecture and technical architecture. I’ve heard of this referred to as the “Four Pillars of EA” – although I’ve also seen articles referring to three and five-pillar variants as well. I’ll go with four since the folks at the Open Group put a lot of work into codifying it. Over the past year plus, I have spent significant time unraveling the mysteries of business, data and technology architecture – but application architecture hasn’t received equal treatment within the curriculum.
So who does application architecture and what does it entail? It turns out that application architecture is carried out at the enterprise level and also at the project level. At the enterprise level, solutions architects are responsible for the concept planning work behind creating reusable assets and work towards the adoption of application development standards and solution patterns (Blechar & Robertson Pt 1, 2010). Solutions architects also coordinate activities which will bring the organization from its current to its planned future state. At the enterprise level, application architects are responsible for designing the solutions defined by the solutions architect. Applications architects are more immersed in the technical specifications of existing systems, and lend insights and the technical design decisions which facilitate the implementation of proposed solutions and standards (Blechar & Robertson Pt 1, 2010).
The output of enterprise-level solutions and applications architects are the frameworks within which the project-level solutions and application architects work. Project-level solutions architects assure that project work is carried out in accordance with the standards and solutions guidance provided by the enterprise-level solutions architects, but do so with a focus on the project to which he or she is assigned. Project-level solutions architects also assure that the right resources are in place to carry out implementation activities (Blechar & Robertson Pt 2, 2010). Project-level applications architects carry out the work of designing reusable application interfaces and software services, such as those utilized for organizations utilizing the SOA development paradigm (Blechar & Robertson Pt 3, 2010). Application architects work closely with business analysts and other subject matter experts to assure that security, business rules and business requirements are well understood among all stakeholders and project team participants.
This all assumes, of course, that the organization is sufficiently resourced and technologically sophisticated enough to require such services. A medium-to-small enterprise may not break out these roles as described as a matter of practicality.
Blechar, M., & Robertson, B. (2010). Application Architecture Overview, Part 1: General Context and Scope. Gartner Database. Article ID: G00208946
Blechar, M., & Robertson, B. (2010). Application Architecture Overview, Part 2:Enterprise-Level Scope and Roles . Gartner Database. Article ID: G00208666
Blechar, M., & Robertson, B. (2010). Application Architecture Overview, Part 3: Project-Level Scope and Roles. Gartner Database. Article ID: G00208668