The Real Impact of IT Owning Your SOA Effort
I had a great lunch discussion today regarding the impact of ownership of SOA within the business. As I have discussed multiple times, SOA is about business services, not technical services, but the reality of this point is lost in semantics. The following illustrates the different perspectives that each have and how that impacts the overall SOA initiative.
Let's look at two business capabilities in real estate: renting the building space (sales) and drawing up rental agreement (legal). Each of these business capabilities are effectively services to the business. In order to operate effectively, they need to share some basic data, such as property listings and renter information (CRM). They also operate synchronously as part of a business process that results in the execution of a rental of a property. Otherwise, they operate fairly autonomously from each other.
From the business' perspective, at a minimum, they'd like one and only one of each of these capabilities, each delivering in a consistent manner. Sometimes, that is not possible. Perhaps, there needs to be two distinct sales teams due to regulatory or licensing issues. In this case, the business will still want the multiple sales teams all operating in a consistent manner, using the same forms, if possible, and interacting with the legal department to draw up the contracts in a consistent manner. The consistency is what enables the business to operate efficiently even in the face of redundancy.
In this particular case, I believe, while not optimal, it is perfectly okay for there to be redundancy of certain information systems in the delivery of each of these business capabilities as long as it allows the business function to deliver consistently and efficiently. For example, if each of these groups had selected a different portal product to provide access to the property listings, that would be acceptable as long as they were operating off the same listings service. Forcing these groups to consolidate on a single portal product is not going to provide any additional efficiencies for these groups or simplify their ability to deliver.
However, what we see happening in the industry, is that SOA efforts are being led by IT and not by the business leaders. Hence, IT views the problem from a systems perspective and sees the need to remove redundancy at the information systems level. So, instead of focusing on business capabilities and making sure that the business rules, processes and goals are being executed consistently and that redundant business capabilities are consolidated, they look at the redundant portals and identify them as a target for consolidation, as so they should. ITs job is to keep IT costs down and are rewarded by simplifying the work of the IT department. However, as I used to remind my developers, it's not about what's easier to code, it's about making the jobs of the users easier, that's why they pay us.
The result of IT forcing consolidation of portal products is some cost savings, but interruption and change for the business. The overall productivity losses within the business function due to the interruption is typically never identified, let alone measured. Users will need to be re-trained on the new portal, things won't work initially and users will become frustrated and be less productive. All of this for the possibility of reducing the costs of managing one additional piece of software.
I say let sleeping dogs lie. There are plenty of real information management costs in most businesses that eliminating will offer a real benefit to the business' bottom line. Clearly, both of the aforementioned business capabilities need to be operating off the same customer and listing data. There's plenty of work to be done by IT without focusing on needless change. Eliminating the additional software licensing costs are penny-wise, pound foolish when the real impact is analyzed and assessed.
With regard to SOA, IT will view SOA as an IT effort that results in consolidation of technical capabilities. That's their task and that's how they are rewarded. IT is not rewarded for improving productivity in payroll by improving the end of month process. And, therein lies the flaw in the system. We have become heavily reliant upon our data and applications to run our business, and therefore, IT has become a critical function of the business. Yet, the business world rewards IT for running with as low of an overhead that can be comfortably be achieved without putting the business at significant risk. If we really expect SOA to live up to its promise, it is going to have to become an effort that is undertaken by the line of business as they reorganize for streamlined operations, or, if we're going to let IT own the SOA, then we are going to have reward IT for improving productivity and usability of the systems in a manner that is best for the users and not necessarily IT. That is, we're going to have to let them focus on actually aligning the information systems with the needs of the business and not force the business to live with the limitations of the systems.
Architecture: 1000 ways to skin the cat, either way, the cat’s till dead
Thanks to @jadkins for the colorful ending to that cliched saying, which really got me thinking. Sometimes we just make certain aspects of architecture too difficult for no reason. Good design is important and can have significant financial impact if done incorrectly, but chances are the negative impact comes into play during the engineering effort, not during the architecture. To clarify my point, one must first understand what architecture is really focused on and how that differentiates from engineering.
For example, if we're designing a solution for financial services products. I can choose to take a framework approach to architecture in which we identify the common financial services components, such as securities and instruments and expose the manipulation of these components through the framework. Then we can continually add new algorithms to manipulate these same components in a modular fashion. Yet, another approach might be to examine things from the perspective of the buyer and the seller and allow each financial product to implement it's own representation of securities and instruments and orchestrate the process of selling and buying.
Either of the aforementioned scenarios is a viable architecture. In the former scenario, we can develop new computational models very quickly as long as we don't change the definition of the semantic elements. However, it can be a bit rigid since all new products must be able to define the components of its product based on these definitions. Also, sharing these products across trading partners becomes more complex.
In the latter scenario, we have a more service-oriented approach, focusing on the consumers and less on the definition of the products themselves. Hence, each service is unique, and may produce redundancy in defining the elements used to create a product, but we can orchestrate buying and selling across products in a common fashion. This approach facilitates incorporation of a much wider community since agreement is not required for the representation of elements to create a new derivatives product.
Which architectural approach is better? Well, as any good consultant will tell you it depends on your goals. If your goal is to allow your big brains to develop new models quickly to identify market making opportunities, then the first approach sounds ideal. If your goal is to enable a new derivative product to be treated as a single instrument even though it's comprised of securities that are bought and sold across a variety of exchanges, then the latter approach will probably suit your needs better than the former.
Neither scenario is optimal or guaranteed, but they both represent a means of simplifying the system enough to extend it over time without considerable re-work efforts.
When complete a design goes through an engineering effort where a software engineer will take this design and "press" it into software. During this effort, decisions are made about platform, programming language, external libraries, software development methodology, etc. Any one of these decisions, or a combination of them, may lead to the undoing of the great abstract architecture designed. For example, if the system cannot scale to the volume of financial services transactions, then that would be one major flaw. Using an open source library that ends up having a major security flaw is another potential flaw.
These scenarios are not very different than design and engineering in any other industry. The architects can design the most awesome car or impressive building, but if the engineers select the wrong parts or use inferior materials, the resulting product will never allow the architecture's brilliance to shine through. Note, manufacturers put significant effort into ensuring that their designs will work by building prototypes and testing against known environments that the product will have to operate under. Thus, from this perspective, architecture is responsible for putting forth a design that is credible before engineering commences.
The Role of The Business Analyst in an SOA World
Those of us that are part of SOA-related projects where traditional business analysts (BA) are involved often find ourselves frustrated by the incongruence between the analyst’s approach to requirements gathering and the SOA design. The problem arises because SOA models functionality of a business across multiple boundaries, whereas the business analyst wants to focus on a user’s needs. One focus is tactical and the other is strategic. However, more than this key difference, certain aspects of the tactical requirements overlap with the strategic requirements; specifically with regard to service boundaries. Thus, important business rules that are relevant to the definition of a particular service are buried among hundreds of irrelevant (to the SOA goals) requirements and the SOA architect is forced to mine these requirements like a miner mining for gold.
In figuring that someone else must have written on this topic, I visited my favorite Web search engine and pulled up the following article: “The new business analyst talks SOA”. I was surprised to find this content on Network World given the nature of the topic, but quickly realized that the author thought of SOA as an application architecture instead of an aspect of Enterprise Architecture. So, it was not much more of a surprise when they recommended that business analysts needed to become more savvy in SOA by learning BPEL, SCA and SDO; perhaps the worst advice I have ever seen regarding this topic. The last thing we want are the business analysts talking about SOA, let alone SODA aspects of SOA.
Still, the article had one point correct, business analysts had better be reading the signs and acclimating themselves to a different type of conversation with their users. Moreover, I believe SOA is a game changer in the way that we collect requirements going forward. For businesses that really want to be successful with SOA, the first conversations that need to be had are with the key business stakeholders, and an Enterprise Architect with SOA experience must be present and facilitating these discussions. This will be the basis for formulating a service model, which will then guide all future system designs. I would also engage a business process engineer to start analysis of business processes that directly impact the effort.
Ultimately, if a BA is able to make the transition to SOA mindset, then they might be a good candidate to drill down and analyze the requirements for the service contract and vocabulary for each service. Otherwise, an SOA architect should really handle these efforts. Which begs the question, what is the role of the BA in an SOA world? I believe there is a need for really good subject matter experts that can work with the Enterprise and SOA architects to fully define the interactions between business functions and, perhaps, to capture the usability models. However, even in the case of usability, a usability expert will offer more insight into how to present information to the user than the BA.
Overall, my analysis is that in an SOA universe, the role of the BA is greatly diminished unless they can adapt to the change in role and gain an understanding of how to facilitate requirements gathering in a much more compartmentalized manner as outlined by the SOA architect and the business process engineer.
The SOA (& Cloud) Funding Dilemma
Lately, and primarily among government users, I've been hearing about a potential clash of bureaucracy meets technology when it comes to funding shared services. It seems that the current government procurement and funding processes do not favor strategic sharing of software services as an outgrowth of a single development effort. I imagine that this issue might also arise in some large organizations where the business units are funding development using a self-funded IT organization, but I have yet to hear any specific stories coming from the private sector regarding this issue.
While there seems to be a number of workarounds to this problem, the basic issue still remains. If one government customer funds the development of an application out of their budget, and in developing that application, it is decided that one or more services could be of use to other government customers, there may be budgetary concerns for actually developing, hosting and maintaining those services for those that are not the original funding customer. Moreover, it becomes questionable how to go about adding features to those services when the requests are not coming from the original funding customer.
With all these government agencies pushing SOA in their IT strategies, one has to wonder, what exactly are they asking for? If the goal is not to remove redundancy within a single department and within a single agency--we're not even focusing on cross-agency here--as a means of reducing costs and providing a single means of delivering a business function in a non-ambiguous manner, then what is the goal?
From my own personal experiences, I believe certain agencies do desire to achieve the benefits of SOA, while others are simply seeking the benefits of component-based architecture, which is flexibility and agility in application design to lower costs of maintenance. However, due to "management by magazine" approaches in IT coupled with the "slap SOA on everything" mandates, agencies that are capable of only benefiting from component-based architecture--because of the procurement and funding issues or just basic needs--are now requesting SOA and ending up spending a lot more to develop a simple application than they should have in the first place and getting a lot more complexity and reliance on middleware infrastructure that is, at best, using a sledgehammer to kill a flea.
Now, most of this entry discusses the issue with regard to SOA, since this is where the problem has really become apparent recently. However, it's not too far of a leap to envision that Cloud Computing, that bastion of shared compute power, is going to have similar and more complex hurdles to overcome with regard to maintenance and operations of applications running in the Cloud. At the end of the day, someone responsible for budgeting today is going to have to figure out how much is required to support and maintain one of their applications next year. That may not be too difficult a task when they are the only group consuming that application, but the budgeting process is far more difficult when that agency accidentally becomes a SaaS provider to other agencies and departments interested in using that application.
Got any private or public sector stories regarding how the budgeting and procurement processes are hindering the strategic value SOA? Please share them with me as I am really interested in understanding the full boundaries of this issue.
SOA & Cybersecurity
I recently started my research into cybersecurity and I am working to become more prolific in this area. Naturally, given my inclination to Service Oriented Architecture (SOA), I am really interested in issues related to both SOA and cybersecurity.
One thing I noticed immediately regarding cybersecurity is that, in general, there are relatively few experts in this area given the total number of IT professionals in the world. This is a known fact. The US Government estimates that we will need on the order of a hundred times more cybersecurity experts in coming years than we currently have. Moreover, due to the nature of work of cybersecurity experts, they don’t readily publish what they know and, thus, it’s even more difficult to expand the pool of cybersecurity experts.
Seek long and hard and you can find some excellent research and literature on the topic of cybersecurity. However, attempting to locate research that covers cybersecurity and SOA was a fruitless endeavor. Sure, we can start with basic concepts like digital signatures, encryption, policy management and access control, however, the literature and examples in these areas often focus on corporate enterprises being operated on secure networks. But, I delve too deeply, too quickly.
In the past, I have been a harsh critic on the lack of consistency of definition and agreement of SOA. Up till now, this has been an academic discussion that isn’t going to greatly impact the universe. If a company wants to build JBOWS (just a bunch of web services), call it their SOA strategy and believe think their acting strategically, so be it. However, lack of agreement on SOA has significant real-world implications with regard to cybersecurity.
If you can’t define it, you cannot secure it!
SOA has become a catch-all for multiple application development and enterprise architecture initiatives. So, if you’re tasked with focusing on cybersecurity for your SOA, you could focus on locking down access to your Web Services, stopping SQL injection attacks, addressing DDoS attacks against the service, etc? Each of these areas requires considerable knowledge of the entire computing stack from telecom through the hardware through the operating system and into the application. Holy rotten fish Batman! That’s a tall order for even the most adept team, but it’s made even more difficult by the fact that there aren’t that many cybersecurity experts available that understands this entire domain.
Additionally, if SOA is the architecture, then shouldn’t security be a primary consideration across the entire architecture? That is, shouldn’t the resulting artifacts of an SOA deliverable address security top-to-bottom? I believe it should, but if you’re in the camp that believes SOA is driven by identifying your service boundaries by your business processes versus business function, then it’s going to be much more difficult to manage appropriate access since processes cross boundaries so often. Nothing screams louder for ensuring proper granularity in an SOA like cybersecurity. A black box is easier to protect than a set of discrete, interconnected nodes.
I’m clearly at the beginning of this exploration. However, what I have experience in with regard to the WS-* security mechanisms, security tools and technologies for securing Web-based and non-Web-based applications, still do not begin to address the real hard issues regarding cybersecurity in an SOA; especially as we expand the notion of service. For example, Twitter, for all intensive purposes, is a service that, according to Twitter staff, was recently unavailable for a considerable amount of time due to directed denial of service attacks.
What if this service was germane to you running your business? Do you still believe WS-* is going to help you protect your SOA-based services? Furthermore, if you take your services into the Cloud, what impact is that going to have on securing your critical business services? The Internet is a darker and grimmer place that the pleasant face we see in Google everyday.
Of note, if you’re a cybersecurity expert looking to mentor someone on the real esoteric issues of how systems are compromised, let me know!
Disclaimer
My Most Recent Book
:Other Links
Web Profiles
Recent Posts
- Cloud Computing Pragmatics
- The Real Impact of IT Owning Your SOA Effort
- Architecture: 1000 ways to skin the cat, either way, the cat’s till dead
- The Busy Executive’s Service Oriented Architecture Reference Guide
- The Busy Executive’s Quick Cloud Computing Reference Guide
Tags
Recent Comments
- Steve Hughes on Cloud Computing Pragmatics
- CloudSigma on Cloud Computing Pragmatics
- Is ‘Service-Oriented Approach’ a Better Way to Define SOA? | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service on Perhaps SOA is More Strategy Than Architecture
- Jaime Ramirez on The Busy Executive’s Quick Cloud Computing Reference Guide
- gon zalez on The Busy Executive’s Quick Cloud Computing Reference Guide
Blogroll
Other Links
Archives
- July 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- March 2009
- February 2009
- January 2009
- September 2008
- August 2008
- May 2008
- December 2007
- November 2006
- April 2005
