by anthonysmoak

From White Hat to Cyber Terrorist: The Seven Types of Hackers

The traditional definition of a hacker is someone who uses computers to gain unauthorized access to data. “Hacks” are deployed for various reasons as diverse as the thrill of the conquest, protests, profit or bolstering status within the hacker community. Some security professionals question whether the term “ethical hacker” is a contradiction in terms, as hacking was originally defined as a criminal activity (Wikipedia, Certified Ethical Hacker).

Conrad Constantine a research engineer at the security management company AlienVault states, “The term ‘ethical’ is unnecessary – it is not logical to refer to a hacker as an ‘ethical hacker’ because they have moved over from the ‘dark side’ into ‘the light’… The reason companies want to employ a hacker is not because they know the ‘rules’ to hacking, but because of the very fact that they do not play by the rules” (Bodhani, pg. 66)

There are many subgroups within the hacker community that encompass more than the traditional black hat, white hat dichotomy. Here are a few of the different types of hackers and their aims:

  • White Hat: Commonly referred to as an Ethical Hacker. Holders of the Certified Ethical Hacker (CEH) certification who uphold the values of the EC-Council (aka the International Council of Electronic Commerce Consultants) would be classified as white hat hackers. The aim of the white hat is to legally and non maliciously perform penetration testing and vulnerability assessments against computer systems in order to improve security weaknesses. White hats are typically employed by security consulting firms that perform penetration testing.
  • Black Hat: Commonly referred to as a “cracker”. Black hats are the opposite of a white hat hacker in that black hats attempt to penetrate computer systems illegally and without prior consent. A Black hat hacker is interested in committing a range of cybercrimes such as identity theft, destroying data, destabilizing systems, credit card fraud etc.
  • Grey Hat: The ethics of the grey hat lies somewhere between those of the white hat and black hat hackers. A grey hat may use the tools and skill sets of a black hat to penetrate into a system illegally but will exhibit white tendencies in that no harm is caused to the system. Typically, the grey hat will notify the system owner of any systems vulnerabilities uncovered.
  • Blue Hat: An outside external security professional invited by Microsoft to exploit vulnerabilities in products prior to launch. This community gathers every year in a conference sponsored by Microsoft; the blue signifies Microsoft’s corporate color. “BlueHat’s goal is to educate Microsoft engineers and executives on current and emerging security threats in an effort to help address security issues in Microsoft products and services and protect customers” (Microsoft, 2013, para. 1)
  • Hacktivists: These hackers will compromise a network or system for political or socially motivated purposes. Website defacement or denial-of-service attacks are the favored methods used by Hacktivists (Wikipedia, Hacker (Computer Security)).
  • Script Kiddies: These “hackers” are amateurs who follow directions and use scripts developed and prepared by advanced hackers. The script kiddie may be able to successfully perform a hack but has no thorough understanding of the actual steps employed.
  • Cyber Terrorists: According to the U.S. Federal Bureau of Investigation, cyberterrorism is any “premeditated, politically motivated attack against information, computer systems, computer programs, and data which results in violence against non-combatant targets by sub-national groups or clandestine agents. Unlike a nuisance virus or computer attack that results in a denial of service, a cyberterrorist attack is designed to cause physical violence or extreme financial harm. According to the U.S. Commission of Critical Infrastructure Protection, possible cyberterrorist targets include the banking industry, military installations, power plants, air traffic control centers, and water systems” (Search Security)

Bodhani, A. (January, 2013). “Ethical hacking: bad in a good way.” Engineering and Technology Magazine, 7(12), Pg.64-64

Cyberterrorism. In Search Security. Retrieved April 16, 2013 from http://searchsecurity.techtarget.com/definition/cyberterrorism

Microsoft. (2013). BlueHat Security Briefings. Retrieved April 16, 2013 from http://technet.microsoft.com/en-us/security/cc261637.aspx

Image courtesy of pat138241 at freedigitalphotos.net

by anthonysmoak

L.A. Lakers Visualization: R Code Plus Illustrator for the Win

I am a huge Los Angeles Lakers fan since I grew up on the West Coast; I lived in Los Angeles for a year and Las Vegas for many years as a kid. Magic Johnson and the “Showtime” squad of the 80’s will always be the best team dynasty in NBA history in my rather biased opinion. I wanted to make a visualization using base R code to plot a bar chart of Lakers wins by season and then use Adobe Illustrator to complete the effort. Using a .csv data file from Basketball-Reference.com I was able to tell the story of the franchise in an easy to comprehend visualization. I love bringing data to life and making it tell a story!

Laker Wins By Season

Twitter Link

by anthonysmoak

Lessons from the Japanese Auto Industry

I spent seven years working at Saturn Corporation which was a truly innovative automotive company. Unfortunately, to the chagrin of Saturn-philes, the subsidiary suffered from a lack of sufficient investment from its parent entity, General Motors. Sadly, the defunct Oldsmobile brand was the recipient of funding that should have been allocated to Saturn but I digress. As an automotive industry veteran (albeit on the I.T. and data side of the house), I enjoyed discussions during my days in business school that focused upon the strategy of companies operating within the industry. In an MBA class titled Managing the Resources of Technological Firms (offered at Georgia Tech), our readings concentrated on the challenges associated with managing a firm’s resource capabilities for long-term competitive advantage.

On such article typifying the aforementioned concentration was written by business historian Michael A. Cusumano. In his article Manufacturing Innovation: Lessons from the Japanese Auto Industry which appeared in the MIT Sloan Management Review, Cusumano sets out to debunk the fact that higher productivity amongst Japanese auto firms is a result of the employment of Japanese workers. He aims to illustrate that the merits of innovative processes are the cause for higher productivity emanating from Japanese owned firms.

The article is in essence a summarization of major findings from a five year study of the Japanese auto industry focusing particularly on Toyota and Nissan. It states that some observers of Japan have assumed that Japanese firms copied US manufacturing techniques and then benefited from a better educated and more cooperative workforce. Cusumano attacks this perception by commenting that Japanese run factories located in the United States have demonstrated higher levels of productivity, quality and process flexibility than their domestic counterparts.

Japanese firms who shunned US or European production techniques were able to innovate and improve upon their native processes. Toyota in particular avoided conventional production techniques and decided to focus on developing a tailored system that met the needs of the Japanese market. Other Japanese firms such as Hino, Daihatsu, Mazda and Nissan started to leverage the techniques employed by Toyota and moved away from the US/European traditional process. Toyota and Nissan appeared to have matched or surpassed US productivity levels by the late 1960’s even though their production levels were far less than US automakers.

Cusumano does not share the Boston Consulting Group’s assessment that Japanese management’s emphasis on long term growth in market shares led to an accumulation of experience. He believes that that the emphasis on the accumulation of experience and innovation led to the rise in market share.

Toyota’s legendary Taiichi Ohno realized that firms needed to be flexible when producing small volumes. Three basic policies were introduced during post war Japan’s auto manufacturing era. Just in time manufacturing reduced buffer stocks of extra components and this small lot philosophy tended to improve quality since workers could not rely on extra parts or rework piles if they made mistakes. The second policy was to reduce unnecessary complexity in product designs and manufacturing processes. Nissan and Toyota standardized components across model lines. The third policy involved a Vertical “De-Integration”. In essence, automakers began to build up a network of suppliers for outsourced component production.

US companies stopped innovating by the early 1960’s as they perceived the domestic auto market as mature. The “American Paradigm” from an automotive production standpoint meant large production runs, worker specialization and statistical sampling. The unique market conditions of Japan after WW2 presented an opportunity for Toyota and other producers to challenge convention and become more efficient at much lower levels of production.

Image courtesy of winnond at FreeDigitalPhotos.net

by anthonysmoak

Visualizations with R and Adobe Illustrator

I’ve been reading Visualize This by Nathan Yau to better understand visualization concepts. The book provides some direction regarding how to begin graphing data in R and then touching up the graphics in Adobe Illustrator. Here are a few visualizations I was able to create with some basic knowledge of R code and Adobe Illustrator. Nathan’s book provides most of the R code but the Illustrator portion took some work to get just right.

This slideshow requires JavaScript.

by anthonysmoak

Billboard Hip Hop Chart Visualized 1989-2015

polygraph-chart-publicenemy-billboard-820

I enjoy a great work of visualization and this interactive data graph by Polygraph charting the top 10 Billboard hip hop hits from 1989-2015 is phenomenal. The number one song in the list plays until it is supplanted by the next number one chart-topping song.

For someone like me who grew up in the 90’s and listened to the golden age of rap music, this graph is a very enjoyable walk down memory lane conjuring up mental images of high school, college and enjoyable times thereafter.  I can pinpoint where I surrendered my knowledge of mainstream hip hop as it ceded to the tastes of a younger generation (around 2011). Enjoy the link:

http://poly-graph.co/billboard/

by anthonysmoak

Enterprise Architecture Best Practice: Communicating & Quantifying Value

One of the common threads that I have come across while researching Enterprise Architecture with respect to its rollout and adoption within organizations is the importance of communication and value quantification.

Many cases studies have hammered home a common theme that communication is a critical success factor in EA engagements. Particular EA challenges include working with a wide assortment of stakeholders who are unfamiliar with EA and how it adds value. A successful EA implementation and adoption depends upon stakeholders having an understanding of how EA adds value.

Bernard, (2012) asserts that translating value to the bottom line is a major concern for key executives and line of business managers with respect to an EA program.  I believe that his list of quantifiable benefits would shore up any “marketing” plan for EA implementation. Blosch (2012) states that EA is quite frequently new to many business executives and that these executives often need help to understand the value that EA is adding. Articulating the value proposition of EA is paramount and the ten benefits as paraphrased from Bernard (2012, pgs. 72-74) are as listed below:

Shortening Planning Cycles: The EA repository provides a wealth of information that is already preassembled for strategic planning or BPI (Business Process Improvement) activities.

More Effective Planning Meetings: EA can help reduce uncertainties by providing a common baseline.

Shorter Decision Making Cycles: A majority of strategy, business and technology information is already pre-vetted and assembled thereby abbreviating the decision making process.

Improved Reference Information: Reference data is gathered using a standardized methodology that lends itself to practicable storage on the EA repository; thus data mining and business analysis capabilities are enhanced.

Reduction of Duplicative Resources: EA enables current enterprise resources to be inventoried and then subsequently analyzed for value overlap and performance gaps.

Reduced Re-work: Greatly reduces potential for individual program level initiatives, which typically involve duplicative processes and implementations if not crafted in sync with an overarching strategy.

Improved Resource Integration and Performance: Resources are planned and utilized on an enterprise-wide basis thus promoting enterprise wide integration. Future state requirements are compared to current state requirements to identify performance gaps.

Fewer People in a Process: EA supports BPR (Business Process Reengineering) and BPI (Business Process Improvement), which can lead to streamlined processes.

Improved Communication: An EA approach helps to reduce misunderstandings and potential rework via a common language of the business.

Reduction in Cycle Time: EA facilitates the capturing of “Lessons learned” from completed projects. These lessons can then be reapplied to future projects making implementation more effective and efficient.

With these ten quantifiable benefits of EA in hand, EA practitioners should work to communicate the benefits of EA to the organization as a whole. Concentrating on gathering executive level support is another key to initial organizational or line of business adoption.  In turn, executives must remain actively engaged in showing their support. They should also communicate expectations that the business should participate in the burgeoning EA or any other process improvement initiative.

Doucet et al (2009 pgs. 460 – 465) describe the AIDA (Attention, Interest, Desire, Action) method that is commonly used in advertising to sway behavior. A marketing communications model is used to push the EA from a level of Unawareness to full Adoption. The full six communications objectives are as follows: Unaware, Awareness, Interest, Desire, Action and Adoption.

At differing stages of the objectives, different communication approaches are employed. In the earlier Unaware states, more broad based statements about EA benefits and effectiveness are communicated. As the objectives move closer to the adoption stage, the details on EA become more focused until actual benchmarks, touchstones and guidelines are shared for full adoption.

In a similar manner, the “Coherency Management State” of an organization ranging from Level 0 (Absent) to Level 5 (Innovating) will dictate communication objectives (Doucet et al., 2009. Pg. 465).

  • Level 0 (Absent): Recognize the importance and create awareness of EA.
  • Level 1 (Introduced): Find an isolated application of EA and encourage use elsewhere in the organization
  • Level 2 (Encouraged): Reinforce and promote values and practices
  • Level 3 (Instituted): Widen the adoption
  • Level 4 (Optimized): Communicate results and organizational wins achieved through EA
  • Level 5 (Innovating): Maintain sustained interest in continuous improvement

Blosch (2012, pg. 10) promotes the idea of recognizing and measuring the impact of a communications strategy to make sure that it is having the desired effect.

Quantitative Measures:

·      Timeliness of communications

·      Production to plan

·      Readership statistics

·      Amount of feedback

·      Number of communications sent out by channel

·      Access and use of EA artifacts

 

 Qualitative Measures

·      Feedback from stakeholders

·      Assessment of stakeholders perception of EA

·      Adoption of EA, where and how widely it is being use

Marketing the EA program with a credible list of quantifiable benefits and paring that list with a robust, well thought out communications strategy should greatly support adoption and diffusion of EA throughout the organization.

References:

Bernard, Scott A. (2012). Linking Strategy, Business and Technology. EA3 An Introduction to Enterprise Architecture (3rd ed.). Bloomington, IN: Author House.

Blosch, M (2012, August 16). Best Practices: Communicating the Value of Enterprise Architecture. Retrieved from Gartner.

Doucet, G., Gotze, J., Saha, P., & Bernard, S. (Eds.). (2009) Coherency Management (1st Ed.). Bloomington, IN: Author House.

Image courtesy of Stuart Miles at FreeDigitalPhotos.net

by anthonysmoak

Enterprise Architecture and Business Process Management

We know that Enterprise Architecture is a logical framework that helps forge a relationship between business, strategy and technology. Within those macro concepts lies various organizational structures, processes and informational flows that help businesses meet their end goals.

With respect to business processes, businesses themselves are dynamic and must change to adapt with the latest market conditions in order to remain a going concern. Thus, proper attention must be paid to processes and the continuous improvement of those processes.

As organizations grow, they need to continuously analyze and refine their processes to ensure they are doing business as effectively and efficiently as possible. Fine-tuning processes gives an organization a competitive advantage in a global marketplace.(Project Management Approach For Business Process Improvement, 2010)

EA and business process management (BPM) are not mutually exclusive. Redshaw (2005. Pg. 3) defines BPM as “the management of all the processes supporting a business transaction/event from the beginning to the end while applying the policies/rules needed to support an organization’s stated business model at a specific point in time.” BPM offers advantages to large institutions as it enables a linkage between IT systems and business processes. Jensen (2010) offers this summarization:

“When done together, BPM provides the business context, understanding and metrics, and EA the discipline for translating business vision and strategy into architectural change. Both are, in fact, needed for sustainable continuous optimization. It is important to realize the value of direct collaboration across BPM and EA boundaries. Only when supported by appropriate collaboration and governance processes can BPM and EA roles work effectively together towards the common goals of the enterprise.” (Jensen, 2010)

EA can support BPM projects by helping project teams become better acquainted with the very processes they are trying to improve. A project manager assigned to a new project can simply access the EA repository to get up to date information on the current processes pertinent to his/her domain. With respect to EA3 framework, “The enterprise’s key business and support processes are documented at the Business level of the EA framework” (Bernard, 2012. Pg. 127).

As processes are improved and changed and project wins or losses are accumulated, this knowledge is shared back into the EA repository for reuse and can be leveraged across the organization.

Quick process improvement wins and one off pinpoint projects may embody a “silo-ed” or parochial approach not in keeping with a broader strategic outlook. Ignoring emerging business strategies can be a costly mistake. For example, energy and resources could be mobilized by a bank to architect a new customer account management or card/payments processing system within the enterprise, accompanied by revised processes. The bank could simultaneously be moving forward with emerging cloud strategies that render the new architected solutions meaningless and obsolete. This hypothetical example of creating solutions in isolation from the overall strategy would be a very costly endeavor in terms of time and money and should obviously be avoided.

By definition, business process management projects embedded within an EA framework are guaranteed to align to the overall organizational strategy. EA becomes a key enabler to ensure process improvement projects are aligned to the strategy for the existing enterprise, as well as any future state strategies.

Wells Fargo and its use of Enterprise Architecture and BPM

As with most organizations of comparable size, Wells Fargo wrestled with issues from both the business and IT (Information Technology) ends of the house. The business had to gain a better understanding of what it needed. It also had to become better acquainted with the capabilities and solutions available from IT. On the other side of the coin, IT had to remain agile enough to deliver and react to changes in business conditions. In this manner IT could be better positioned to deliver solutions that met various business needs.

Olding (2008) found that Wells Fargo operated a very decentralized structure but lacked the coordinated ability to understand what was occurring in other groups that were employing business process management initiatives. A disadvantage of not embedding the BPM experiences within an EA framework was the failure to capitalize on successes that were gained across other “silo-ed” groups. Integrating EA into the approach dramatically simplified the process of capturing those wins for organizational reuse.

At Wells Fargo, a BPM Working Group was established with EA as its champion. The business set out to capture the current state of BPM technologies and approaches around a dozen lines of business. The results indicated that there were over 20 different BPM technologies being employed, each with their own varying approaches to implementation (Olding, 2008). In order to maximize the value of BPM, coordination had to occur across these lines of business.

A seasoned Enterprise Architect within the company made use of a communications strategy to raise awareness of the duplicative uncoordinated approaches dotting the landscape. Business analysts, project managers, executives, and technology professionals were engaged and best practices from the various approaches were discussed and reworked into an EA framework.

A year later, senior executives were presented with the best practices from various approaches, which had since been re-developed using a common framework. The commonality gained from the EA framework allowed for patterns of success to be easily identified, communicated and thus ultimately standardized. With senior level executive backing, the EA framework will persist in the organization allowing the bank to quickly identify opportunities for standardization.

Burns, Neutens, Newman & Power (2009, pg. 11) state, “Successful EA functions measure, and communicate, results that matter to the business, which in turn only strengthens the message that EA is not simply the preserve of the IT department.” This dovetails into the approach that Wells Fargo’s Enterprise Architect employed; the communication of pertinent information back to various business lines to gain acceptance.

The lessons learned from Wells Fargo’s use of BPM and EA as paraphrased from (Olding, 2008. Pgs 5-6):

  • Communicate at all levels of the enterprise.
  • Build BPM adoption from the bottom up. Approach business groups with proven examples and internal successes that will help drive the willingness to adopt new approaches.
  • Facilitate, do not own. Allow business groups to manage their own processes aligned within the framework.
  • Build EA from the top down.
  • Use BPM to derive the needed context and then incorporate it into the EA

As of 2008 Wells Fargo Financial (a business unit of the Wells Fargo & Co.) currently had nine BPM deployments in production and another four projects in the works. Gene Rawls, VP of continuous development, information services, for Wells Fargo Financial has stated that not having to reinvent the wheel saves months of development work for every deployment (Feig, 2008). Project turnaround time from the initial go-ahead for a BPM project to its actual deployment, is just three months.

References:

Bernard, Scott A. (2012). Linking Strategy, Business and Technology. EA3 An Introduction to Enterprise Architecture (3rd ed.). Bloomington, IN: Author House.

Burns, P., Neutens, M., Newman, D., & Power, Tim. (2009). Building Value through Enterprise Architecture: A Global Study. Booz & Co. Retrieved November 14, 2012.

Feig, N. (2008, June 1). The Transparent Bank: The Strategic Benefits of BPM — Banks are taking business process management beyond simple workflow automation to actually measure and optimize processes ranging from online account opening to compliance. Bank Systems + Technology, Vol 31. Retrieved from Factiva database.

Olding, Elise. (2008, December 7). BPM and EA Work Together to Deliver Business Value at Wells Fargo Bank. Retrieved from Gartner October 29, 2012.

Jensen, Claus Torp. (2010, February 10). Continuous improvement with BPM and EA together. Retrieved November 13, 2012.

Project Management Approach For Business Process Improvement. Retrieved November 12, 2012 from http://www.pmhut.com/project-management-approach-for-business-process-improvement

Redshaw, P. (2005, February 24). How Banks Can Benefit From Business Process Management. Retrieved from Gartner October 29, 2012.

Image courtesy of Stuart Miles at FreeDigitalPhotos.net

 

by anthonysmoak

The Competitive Advantage of Process Innovation

This post summarizes a Harvard Business Review article entitled “The New Logic of High-Tech R&D“, written by Gary P. Pisano and Steven C. Wheelwright. The article focuses on the revelation that few companies within the pharmaceutical industry view manufacturing and process improvement as a competitive advantage. The authors assert that manufacturing process innovation is conducive towards product innovation. Companies traditionally spend money on product R&D but tend to neglect focusing on process R&D.

For example, Sigma Pharmaceuticals refused to invest significant resources to process development until the company was confident that the drug would win FDA approval. As a result, when demand for the drug increased they could not meet the higher demand without major investments in additional capacity. During this interim ramp up period the company lost two years of potential sales. Underinvestment in process development on the front end clearly put the company in a sub-optimal position to capitalize on additional revenue.

Process development and process innovation provide a litany of benefits. The first of which is accelerated time to market. According to one drug company, the time required to prepare factories for production generally added a year to the product-development lead time. Senior management was unaware of this fact while the managers within the process development organization were fully aware.

Rapid ramp up is also invaluable because it allows companies to more quickly realize revenue, penetrate a market, and recoup its development investments. Also the faster the ramp up occurs the faster critical resources can be freed to support the next product.

Innovative process technologies that are patent protected can hinder a competitor’s push into the market. Pisano and Wheelwright state that it is easier to stay ahead of a competitor that must constantly struggle to manufacture a product at competitive cost and quality levels.

Process development capabilities can also serve as a hedge against various forces in high tech industries. Shorter lifecycles elevates the value of fast to market processes. Semiconductor fabrication facilities can cost upwards of one billion dollars and depreciate at a rapid pace. For this reason, rapid ramp up is very important. Those companies with strong process development and manufacturing capabilities will have more freedom in choosing the products they wish to develop rather than forced to stick with simple to manufacture designs.

Pharmaceutical companies traditionally operated in the following manner. They delayed significant process R&D expenditures until they were reasonably sure that the product was going to be approved for launch. They didn’t delay product launch by keeping the process R&D off of the critical path. Manufacturing and process engineering were on hand to make sure the company could bring on additional capacity and didn’t stock out. Manufacturing was located in a tax haven even if it was far from R&D and process development, while process development was introduced later in the lifecycle in order to thwart the threat of generic competition. Today however, pharmaceutical companies find themselves squeezed by shorter product life cycles, less pricing flexibility and higher costs.

The article states that the earlier that a company makes process improvements the greater the total financial return. It is costly and time consuming to rectify process design problems on the factory floor. The earlier these problems are found in the development cycle the shorter the process development lead time.

Image courtesy of Areeya at FreeDigitalPhotos.net

by anthonysmoak

The Benefits of Service Oriented Architecture for Financial Services Organizations

The banking and financial industry is an industry where legacy systems are prevalent. Banking systems tend to skew older and are very heterogeneous in nature. This heterogeneity of legacy banking systems is also coupled with the fact that replacement and integration of these systems is a difficult undertaking.

Mazursky (as cited in Baskerville, Cavallari, Hjort-Madsen, Pries-Heje, Sorrentino & Virili, 2010) states that older architectures complicate integration of enterprise applications because the underlying elements have created ‘closed’ architectures. Closed architectures restrict access to vital software and hardware configurations and force organizations to rely on single-vendor solutions for parts of their information computer technology. Thus, closed architectures hinder a bank’s ability to innovate and roll out new integrated financial products.

The flexibility of SOA facilitates easier connectivity to legacy backend systems from outside sources. Because of the size and complexity of most enterprise banking systems, a potential reengineering of these systems to flawlessly accommodate interaction with newer systems is not economically feasible. Inflexible systems can be difficult to modernize and maintain on an on-going basis. Furthermore, banks’ legacy systems can suffer from a lack of interoperability, which can stifle innovation.

“According to a survey commissioned by Infosys and Ovum in May 2012, approximately three quarters of European banks are using outdated core legacy systems. What’s more, 80% of respondents see these outdated systems as barriers to bringing new products to market, whilst 75% say such systems hinder, rather than enable, process change. Integration cost is effectively a barrier to service provision flexibility and subsequent innovation” (Banking Industry Architecture Network, 2012).

The greater the number of banking systems that can easily interact, connect and share data with other systems and services, the more innovative banks can become with respect to their product offerings for consumers. Market demands can be more easily responded to when new product creation is allowed to flourish with appreciably lower system integration costs. New applications can also be developed in much shorter time frames in order to react to customer demand as long as services are maintained and shared across the enterprise.

According to Earley & Free (2002), a bank that identifies a new business opportunity such as wealth management but has never provided such a service in the past can quickly ramp up functionality by utilizing services previously designed for other applications. The new wealth management application is designed without duplicating functionality in a more cost efficient and rapid manner. Smaller and mid-tier banks can capitalize on bringing new applications and services to market quickly and economically. This responsiveness allows smaller banks to offer similar products as those offered by their larger competitors. The modularity of SOA design precludes the need for substantial re-engineering of smaller/mid-tier banks’ information computer technology. This is an important benefit because smaller banks do not have comparable financial resources with respect to the more sizable industry players.

Additionally, SOA has the potential to free up development resources sooner, enabling those resources to engage in other development initiatives. “Few banks will be able to buy or build new capabilities quickly enough to satisfy market requirements without an SOA” (Earley & Free, 2002). In the survey conducted by Infosys Consulting and Ovum (a London based research organization), 100% of banks responded that SOA would become the “dominant, accepted future banking architecture“ (Banking Industry Architecture Network, 2012).

Furthermore, banks can employ multiple services to complete a business process. One service that determines the value of a portfolio of financial assets at market rates (mark to market calculations) could be coupled with another service that calculates the Value at Risk (VaR) of the bank’s entire portfolio. In a similar fashion to the new wealth management application example previously cited, the dual components could be made available to many other enterprise wide financial services and applications that require portfolio valuation and risk related information. In this manner, the functionalities are not inefficiently repeated across every application where they are requested.

Additionally, via use of SOA, “New technology provides the ability to mix and match outsourced business processes with on-premise assets and services” (Essvale Corporation Limited, 2011). Software designed or in use by third party vendors can become more easily integrated with bank systems and processes due to the high connectivity of an SOA approach. According to Gartner research, smaller and mid-tier banks are adopting SOA in order to make the most of their limited IT budgets and resources. “Until now, midtier banks had to rely on customized software packages from a single vendor, and assumed all of the maintenance costs and function limitations inherent in a single, proprietary set of solutions” (Earley et al., 2005). Due to a rising interest in SOA, technology vendors that serve the financial services industry are increasingly working with integration providers to offer a standard set of component integration (Earley, et al., 2005).

One of the benefits of SOA standardization is the enablement of more functionality, performed by much less underlying code. This leads to less complex, more cost effective system maintenance; thereby reducing operational risks.

“A fully implemented SOA provides a bank with a highly predictable application environment that reduces risk in day-to-day operations, due to the minimization and isolation of change to the production systems. Banks that fail to take this approach must constantly change their interfaces as external and internal requirements change. This introduces significant risk and the need for near-continuous testing to ensure that the customer ‘touchpoints’ and the back-end processes do not fail, while ensuring that one data or service change doesn’t adversely affect other data changes integrated through an interface” (Earley et al., 2005).

Conclusion

SOA has an important role to play in the architectural repertoire of banking and financial organizations. Its loosely coupled design characteristic allows services to be shared and reused across the enterprise without disparate systems concerning themselves with the underlying development code. Multiple services can be combined together to form reusable chunks of a business process. Outside sources can connect to legacy backend systems via an API, which increases the opportunity to mix and match vendor capabilities with in-house assets. SOA also helps banks and financial firms ramp up new applications and functionality quickly and economically, increasing product responsiveness to market demands. When SOA is combined with Event Driven Architecture, dynamic event driven systems can be developed that do not rely solely on the less proactive request/reply paradigm.

Banks and financial companies need to remain innovative, cost effective and anticipate customer needs in order to remain profitable. SOA allows organizations to become more agile and flexible with their application development. The rise of applications on mobile cloud enabled platforms means that customers will need to connect to data wherever it dwells. “Bank delivery is focused on reactively providing products on customer request, and mass-market, one-size-fits-all products (for mainstream retail banking). However, it is no longer feasible to force-fit mass-market bank products when technology devices, context and location are key elements to the type of customized bank service a customer needs” (Moyer, 2012). As SOA continues to mature with cloud enabled solutions and the rise of mobile computing, it is primed to be the building block for the next generation of banking application functionality.

References:

Baskerville, R., Cavallari, M., Hjort-Madsen, K., Pries-Heje, J., Sorrentino, M., & Virili, F. 2010. The strategic value of SOA: a comparative case study in the banking sector. International Journal of Information Technology and Management, Vol. 9, No. 1, 2010

Banking Industry Architecture Network. (2012). SOA, standards and IT systems: how will SOA impact the future of banking services? Available from https://bian.org/wp-content/uploads/2012/10/BIAN-SOA-report-2012.pdf

Early, A., & Free, D. (2002, September 4). SOA: A ‘Must Have’ for Core Banking (ID: SPA-17-9683). Retrieved from Gartner database.

Early, A., & Free, D., & Kun, M. (2005, July 1). An SOA Approach Will Boost a Bank’s Competitiveness (ID: G00126447). Retrieved from Gartner database.

Essvale Corporation Limited. (2011). Business knowledge for it in global retail banking: a complete handbook for it professionals.

by anthonysmoak

Overview of Service Oriented Architecture

 

Service Oriented Architecture (SOA) can be described as an architectural style or strategy of “building loosely coupled distributed systems that deliver application functionality in the form of services for end-user applications” (Ho, 2003). Ho (2003) proclaims that a service can be envisioned as a simple unit of work as offered by a service provider. The service produces a desired end result for the service consumer. Another way to envision the concept of a service is to imagine a “reusable chunk of a business process that can be mixed and matched with other services” (Allen, 2006). The services either communicate with each other (i.e. pass data back and forth) or work in unison to enable or coordinate an activity.

When SOA is employed for designing applications and/or IT systems, the component services can be reused across the enterprise, which helps to lower overall development costs amongst other benefits. Reuse fosters consistency across the enterprise. For example, SOA enables banks to meet the needs of small, but profitable market segments without the need to redevelop new intelligence for a broad set of applications (Earley, Free & Kun, 2005). Furthermore, any number of services can be combined together to mimic a business processes.

“One of the most important advantages of a SOA is the ability to get away from an isolationist practice in software development, where each department builds its own system without any knowledge of what has already been done by others in the organization. This ‘silo’ approach leads to inefficient and costly situations where the same functionality is developed, deployed and maintained multiple times” (Maréchaux, 2006).

Architectural Model

Services are only accessed through a published application-programming interface, better known as the API. The API, which acts as the representative of the service to other applications, services or objects is “loosely coupled” with its underlying development and execution code. Any outside client invoking the service is not concerned with the service’s development code and is hidden from the outside client. “This abstraction of service implementation details through interfaces insulates clients from having to change their own code whenever any changes occur in the service implementation” (Khanna, 2008). In this manner, the service acts as a “black box” where the inner workings and designs of the service are completely independent from requestors. If the underlying code of the service were switched from java to C++, this change would be completely oblivious to would-be requestors of the service.

Allen, (2006) describes the concept of loose coupling as, “a feature of software systems that allows those systems to be linked without having knowledge of the technologies used by one another.” Loosely coupled software can be configured and combined together with other software at runtime. Tightly coupled software does not offer the same integration flexibility with other software, as its configuration is determined at design-time. This design-time configuration significantly hinders reusability options. In addition, loosely coupled applications are much more adaptable to unforeseen changes that may occur in business environments.

In the early 1990’s some financial firms adopted an objected oriented approach to their banking architecture. This approach is only superficially similar to a service oriented architecture approach. In an object oriented (OO) approach, the emphasis is on the ability to reuse objects within the source code. SOA emphasizes a “runtime reuse” philosophy in which the service itself is discoverable and reused across a network (Earley, Free & Kun, 2005). SOA also provides a solution to the lack of interoperability between legacy systems.

References:

Allen, P. (2006). Service orientation: winning strategies and best practices.

Early, A., & Free, D., & Kun, M. (2005, July 1). An SOA Approach Will Boost a Bank’s Competitiveness (ID: G00126447). Retrieved from Gartner database.

Ho, H. (2003). What is Service-Oriented Architecture? O’Reilly XML.com.

Khanna, Ayesha. (2008). Straight through processing for financial services: the complete guide.

Maréchaux, J., (2006, March 28). Combining Service-Oriented Architecture and Event-Driven Architecture using an Enterprise Service Bus. IBM developerWorks. Retrieved from http://www.ibm.com/developerworks/library/ws-soa-eda-esb/