Blogging Is My Civic Duty
Why do I blog?
For me it's a civic duty. I have an ability to identify the real value of IT investments and directions to business. There's a lot of noise out there coming from sources with their own agendas, both internal and external to an organization, that makes it difficult to fully understand the long term impact of any IT decision.
Overall, most IT failures have been washed away in short time spans, perhaps the IT leader suffered a political death in the organization, if not downright asked to leave, but overall the business does not abandon the solutions that are working, even if they are not working effectively. However, these continual failures do have an aggregate effect in wearing away confidence, which has an overall negative effect on the industry in which I make my living. As more business leaders lose faith that IT can be used to directly help them, the less inclined they are to spend and grow this industry.
I view my content as putting out some filters into the system to balance the noise. We all have an agenda, and mine is to improve the quality of information available to business decision makers regarding emerging directions in IT. However, my agenda is not self-serving with the exception of improving the entire community, thus, my information should be deemed trustworthy. Moreover, my blog, articles and community discussion input provide real discussion and enhance the overall quality of the conversation around these topics, which delivers greater value than reading a vendor-sponsored white paper.
The realities of the situation is this, executive business leaders need a system of checks and balances for IT acquisitions within their own organization. 99.999% of people attempt to forward their own agendas. Sometimes, those are aligned with the mission and sometimes they are not. Projects that are the equivalent of the "hail mary" play in the final seconds of the game to win, or promote oneself as the hero of the day, often end up being dropped passes that waste precious time and money. If I was a CEO or CFO that was not technically savvy, I'd make sure I had an advisor that could assess and provide objective feedback on the direction and decisions of IT management, which, by the way, is a great role for an Enterprise Architect.
My agenda is simple, improve the quality and reliability of solutions being provided by the IT industry as a whole. To make sure that IT decisions are vetted for economic feasibility and provide real value toward the mission of the organization. And, most of all, to raise the overall confidence of business in investing long-term IT investments that ensure continuity of the business in a world of growing uncertainty. While we cannot know what will happen tomorrow, we do have the ability to lay a foundation that will allow faster response to changes as they occur. Moreover, this goes beyond pure software, but the way we deliver IT as a service in general.
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.
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
