The concept of dynamic endpoint selection sounds really neat. At service runtime, the service consumer need not know what service is going to be invoked to fullfill its invocation request; rather, a SOA governance tool can help faciliate this decision of choosing a providing service, based on the pre-defined contractual functionality, interface, SLA, and policy. The SOA governance tool will choose the best service to invoke to accomplish the consumer's requests, bind the consumer to the provider, and complete the "transaction". This sounds super helpful and a bit optimistic, but is it practical? In other words, Are there really architectures using this approach of having services "swap in and swap out" at runtime according to the consumer's needs? I've only had 1 customer to date consider this feature of SOA, as most don't have a complex enough requirement to justify the feature in the architecture. A couple things come to mind when thinking about this capability:
-- Dynamic Endpoint Selection is probably most applicable with external hosted services, outside your corporate firewall. For example, if I need to get a stock quote or a weather service, I probably have less concern about who the Provider is, as long as my Quality of Service (QoS) needs are met. Just get me the info! However, internally hosted services won't have backups that applicable to my business. Getting customer or Supply Chain information that is specific to my business is impossible to replicate externally, or is just questionable architecture if it is redundant internally (putting failover and D/R aside).
-- This could work well in a B2B scenario or for a multi-agency government scenario. This is better known as a Community Cloud. If one provider can not provide a consumer the information needed at the time the consumer needs it, another provider can "step in" and fullfill the request. In a community, a lot of the participants have access to same or similiar information sources.
-- This could be really nice to automate a B2C retail online transaction. I don't need to know who the merchant is selling the product, just the price and terms. In Amazon, we get presented with a checkout to a specific merchant. What if I don't ever need to know who the merchant is until after purchase (like hotwire.com). Rather, a service does the dynamic selection. This would assume vendors have connected their inventory systems into the marketplace for an automated inventory check before purchase order completes. Still, today's buyer is normally accustomed to know who they are buying a product from before the committ to purchase. Part of this is brand identify, part educated consumer, and part skepticism with all the horror stories of purchasing products over the Internet.
-- Creating the general interface contract and getting proper provider compliance can be cumbersome. Does the end justify the means? How many consumers will use this approach, if the investment is put up from the providers?
Monday, June 21, 2010
Friday, June 11, 2010
Cloud & Compliance: Write a Solid Prenup
I am getting a lot of questions lately about Cloud and Regulatory compliance, especially around Sarbanes Oxley and PCI. This entry will provide some high level guidance on what to pay attention to with Sarbanes, PCI, and Cloud Computing.
Regarding Sarbanes, first, there has to be an understanding that data ownership and data control are different responsibilities and capabilities assigned to a Provider-to-Consumer relationship. Without question, a cloud consumer should have full data ownership, but definitely check your provider's contract to be sure of this. You own the data and the intellectual property tied to the data because you created it and did not assign it to the provider. Data Control is a little different. You would like to have full accessibility and control as a cloud consumer, but certainly negotiate that with your Cloud provider on what control you do get. You might not get full control from the provider, but you should have something close to this, in case you need to react quickly to an issue or new demand. To pass some of these Sarbanes regulations, ask your Cloud Provider if they have passed a SAS 70 audit. It is important that they have. This type of audit is performed by an independent audit firm, and verifies the provider has proper IT controls in place. It is a Federal Regulation But, also ask your cloud provider for the details of the Type II SAS 70 report, so you can read through the actual descriptive items addressed in the report outcome. This report will have User Defined Controls and tells how well the provider is adhering to these controls. An example of a User Defined Control would be if the cloud provider fires the Administrator on your account, they need to immediately be removed from having access to your cloud. That is an example of a User Defined Control-- accessibility to the information source during employee de-provisioning. With these SAS 70 reports in place, your cloud provider should be Sarbanes compliant !
Regarding PCI, which involves governing controls of sensitive information such as credit card numbers and its associated information, the industry standards are less mature. There is a PCI Compliance certification, and it is a good thing to ensure you cloud provider has done such a certification. However, it is not on the same level as a Sarbanes SAS 70 audit, because it is not always through a 3rd-party and it is not a Federal Regualtion. There have been too many breaches of PCI Compliant systems to claim this as a regulation, even though some states are starting to pass laws around PCI protection. So, its a "nice to have" certification, but not a "requirement" like SAS 70 is. This is because its not an industry standard and technically doesn't validate the provider as passing an independent audit. STill, I highly recommend having it done if you are going to do PCI in the cloud, just don't rest your laurels on it. To further beyond the certification, you need to discuss with your provider how they are doing encryption, security, data privacy, data masking, data protection (virtual and physical) and so forth to ensure the PCI data is well protected to the highest level of trust.
The big thing for cloud consumers to remember is to do your homework on your provider. Read their contracts, negotiate their contracts, have your legal read the contracts, review SLA's, and just ensure you are well protected from catostrophes. This is where the rubber meets the road to ensure you are protected should an issue arise-- make sure the contract is bullet proof. Think of your cloud contract as a prenuptual agreement-- what happens when things wrong and how do the parties react? There has to be clear recourse and comittments. Putting this together, will help everyone sleep better at night.
Regarding Sarbanes, first, there has to be an understanding that data ownership and data control are different responsibilities and capabilities assigned to a Provider-to-Consumer relationship. Without question, a cloud consumer should have full data ownership, but definitely check your provider's contract to be sure of this. You own the data and the intellectual property tied to the data because you created it and did not assign it to the provider. Data Control is a little different. You would like to have full accessibility and control as a cloud consumer, but certainly negotiate that with your Cloud provider on what control you do get. You might not get full control from the provider, but you should have something close to this, in case you need to react quickly to an issue or new demand. To pass some of these Sarbanes regulations, ask your Cloud Provider if they have passed a SAS 70 audit. It is important that they have. This type of audit is performed by an independent audit firm, and verifies the provider has proper IT controls in place. It is a Federal Regulation But, also ask your cloud provider for the details of the Type II SAS 70 report, so you can read through the actual descriptive items addressed in the report outcome. This report will have User Defined Controls and tells how well the provider is adhering to these controls. An example of a User Defined Control would be if the cloud provider fires the Administrator on your account, they need to immediately be removed from having access to your cloud. That is an example of a User Defined Control-- accessibility to the information source during employee de-provisioning. With these SAS 70 reports in place, your cloud provider should be Sarbanes compliant !
Regarding PCI, which involves governing controls of sensitive information such as credit card numbers and its associated information, the industry standards are less mature. There is a PCI Compliance certification, and it is a good thing to ensure you cloud provider has done such a certification. However, it is not on the same level as a Sarbanes SAS 70 audit, because it is not always through a 3rd-party and it is not a Federal Regualtion. There have been too many breaches of PCI Compliant systems to claim this as a regulation, even though some states are starting to pass laws around PCI protection. So, its a "nice to have" certification, but not a "requirement" like SAS 70 is. This is because its not an industry standard and technically doesn't validate the provider as passing an independent audit. STill, I highly recommend having it done if you are going to do PCI in the cloud, just don't rest your laurels on it. To further beyond the certification, you need to discuss with your provider how they are doing encryption, security, data privacy, data masking, data protection (virtual and physical) and so forth to ensure the PCI data is well protected to the highest level of trust.
The big thing for cloud consumers to remember is to do your homework on your provider. Read their contracts, negotiate their contracts, have your legal read the contracts, review SLA's, and just ensure you are well protected from catostrophes. This is where the rubber meets the road to ensure you are protected should an issue arise-- make sure the contract is bullet proof. Think of your cloud contract as a prenuptual agreement-- what happens when things wrong and how do the parties react? There has to be clear recourse and comittments. Putting this together, will help everyone sleep better at night.
Thursday, June 3, 2010
EA and SOA Should Report to COO
There is a debate fuming across companies worldwide-- where to organizationally structure the Enterprise Architecture (EA) team? IT makes a compelling case that they enable the capabilities to support the business through systems, information, and tools and therefore should own the EA group. Business makes a compelling case because they are the reason the company even exists in the first place, and they know the business processes, business capabilities, and business models-- they don't see any reason they shouldn't control EA.
So, who gets EA-- the CIO or VP of a Business? I argue neither! After all, a typical EA goal is to connect the Business and IT together to impart better structure and visibility across the enterprise. I firmly believe that neither should own EA so that neither imparts too much of their organization (i.e bias) on the EA process and deliverables. EA needs to be independent, and it's for all the right reasons.
Companies need to seriously consider organizationally aligning EA into a group that is independent of both IT and Business. The easiest way to do this is to let the COO own EA and let his group facilitate the collaboration between IT, Business, and EA group too. The COO already has been assigned corporate responsibility for governance, operations, company performance, prioritizing organizational requirements. This sounds like a natural fit for Enterprise Architecture to me.
Wait, you don't have a COO? Now's the time to create one! If that's a tough sell to your CEO, then I still recommend keeping EA outside the groups its supposed to connect, namely IT and Business. You could do a stop gap an align EA in IT department like most organizations do today...but you've now lost your independence, and even worse, credibility with the business. There's already enough distrust, why create more? With such an approach it's really easy to impart a bias, even worse a political opinion or even a resentment too. Anyone whose worked in corporate world knows this all too well. EA is chartered to break-down these silo's, tear down walls, and build bridges across the organization. With the wrong organizational alignment, it could be the cause for divide. We don't want EA to be the corporate joke punchline, and the only way to prevent this is keep the EA team at arms length, by putting it in a separate team, with separate alignment. And, this applies to SOA as well. After all, the SOA and EA team should already be in the same team, a topic I'll address in another blog entry.
So, who gets EA-- the CIO or VP of a Business? I argue neither! After all, a typical EA goal is to connect the Business and IT together to impart better structure and visibility across the enterprise. I firmly believe that neither should own EA so that neither imparts too much of their organization (i.e bias) on the EA process and deliverables. EA needs to be independent, and it's for all the right reasons.
Companies need to seriously consider organizationally aligning EA into a group that is independent of both IT and Business. The easiest way to do this is to let the COO own EA and let his group facilitate the collaboration between IT, Business, and EA group too. The COO already has been assigned corporate responsibility for governance, operations, company performance, prioritizing organizational requirements. This sounds like a natural fit for Enterprise Architecture to me.
Wait, you don't have a COO? Now's the time to create one! If that's a tough sell to your CEO, then I still recommend keeping EA outside the groups its supposed to connect, namely IT and Business. You could do a stop gap an align EA in IT department like most organizations do today...but you've now lost your independence, and even worse, credibility with the business. There's already enough distrust, why create more? With such an approach it's really easy to impart a bias, even worse a political opinion or even a resentment too. Anyone whose worked in corporate world knows this all too well. EA is chartered to break-down these silo's, tear down walls, and build bridges across the organization. With the wrong organizational alignment, it could be the cause for divide. We don't want EA to be the corporate joke punchline, and the only way to prevent this is keep the EA team at arms length, by putting it in a separate team, with separate alignment. And, this applies to SOA as well. After all, the SOA and EA team should already be in the same team, a topic I'll address in another blog entry.
Wednesday, May 26, 2010
Want Free ERP Software Advice?
I was recently introduced to the website Software Advice because they wrote an Introductory Article on SOA entitled The Plain English Guide. It's a pretty good overview for any beginner to SOA trying to grasp the fundamental concept.
Tuesday, May 11, 2010
Will Cloudsourcing Change the Face of Consulting?
Some say a perfect storm is brewing that will change the face of consulting forever. It is called Cloudsourcing and it is the combination of: Cloud Computing + Online Collaboration + Inexpensive labor + tightening corporate purse strings =
• More Offsite (and offshore) consulting
• Shorter and less expensive IT and consulting projects
• More pre-built deliverables such as software applications
• Commoditization of IT in general
Could this be true? Will we all be working remotely to deliver our client projects going forward? Maybe someday, but not anytime soon. Sure there will be projects that fall perfectly inline for Cloudsourcing, such as Small/Medium size businesses who loathe infrastructure, software firms who are well organized to hire and on-board offshore, and high-tech companies who have already accomplished manufacturing outsourcing.
But,I challenge that there is still and always will be a strong need for more soft skills then hard, more white collar than blue, and more human elements that can never be replaced. Now, I'm not blind and I clearly see there will continue to be a push to off-shore more IT labor to save costs, and I think this works well when projects are in well-defined “Development” phases that software engineers can work remotely, effectively. However, here are reasons I believe Cloudsourcing will be a slower adoption than some are predicting:
• There is still too much confusion with Cloud Computing among IT departments. Face it, there are very few cloud pioneers, and most organizations are taking a “wait and see” approach. Most of the Fortune 2,000 and Federal government agencies, who are the ones who spend the most consulting dollars, haven’t jumped onto the Cloud bandwagon quite yet. Although a lot are investigating and interested in Cloud because they know this is the future of computing, they haven’t committed yet and probably won’t for a couple more years. Some say the pioneers are the ones with arrows in their backs, and this is why a lot of CIO's are letting their peers forge into the Cloud before they are. Cloud is inevitable, it is certainly they direction our industry is moving; it's just moving a little slower than some predicted.
• It’s hard to see eye to eye when you can’t see face to face. I believe it was Hilton Hotel’s marketing program that launched that slogan. And it’s too often true. There is too much human element in IT projects that cannot be accomplished through teleconferences, online collaboration, email, or other non-human mediums. It reminds me of the "Jay Cutler Conference Call Fiasco" that any Bronco's fan remembers. You have to meet people in person, and that is why there are so many consulting road warriors out there.
• Think about it…how many of these initiatives can be successfully completed without face to face meetings: Requirements Management, Project Management, Enterprise Architecture, Governance, Technology Insertion, Portfolio Management, Program Management, Communication Management
• Off shoring of Operations, Maintenance, Sustainability, Support, and Administration to me makes a lot of sense. However, off shoring innovation, business requirements, prototypes, and new ideas to me seems risky. I’ve always claimed off shoring is a delicate balance of quality vs. cost and anyone who has been on an offshore team knows how well the product or deliverable needs to be specified before handing over to the offshore team to develop it. Also, I've experienced off-shoring may be cheaper, but it's also slower so anything that is requiring rapid market penetration, flexibility to change on the fly, or time sensitive may not be the best candidate for this model.
Ultimately, we will see minor shifts to more cloudsourcing type models, but certainly no wholesale shifts. Small and Medium sized businesses are prime candidates and are already beginning to embrace this model. It makes sense for them. It just doesn't make sense for the typical Fortune 2000 corporate culture, especially for their strategic initiatives. Don't get me wrong-- I'd like to see the model work and spend less time in airports myself, I just don't think corporate culture is ready for such a monumental shift in consulting models anytime soon.
• More Offsite (and offshore) consulting
• Shorter and less expensive IT and consulting projects
• More pre-built deliverables such as software applications
• Commoditization of IT in general
Could this be true? Will we all be working remotely to deliver our client projects going forward? Maybe someday, but not anytime soon. Sure there will be projects that fall perfectly inline for Cloudsourcing, such as Small/Medium size businesses who loathe infrastructure, software firms who are well organized to hire and on-board offshore, and high-tech companies who have already accomplished manufacturing outsourcing.
But,I challenge that there is still and always will be a strong need for more soft skills then hard, more white collar than blue, and more human elements that can never be replaced. Now, I'm not blind and I clearly see there will continue to be a push to off-shore more IT labor to save costs, and I think this works well when projects are in well-defined “Development” phases that software engineers can work remotely, effectively. However, here are reasons I believe Cloudsourcing will be a slower adoption than some are predicting:
• There is still too much confusion with Cloud Computing among IT departments. Face it, there are very few cloud pioneers, and most organizations are taking a “wait and see” approach. Most of the Fortune 2,000 and Federal government agencies, who are the ones who spend the most consulting dollars, haven’t jumped onto the Cloud bandwagon quite yet. Although a lot are investigating and interested in Cloud because they know this is the future of computing, they haven’t committed yet and probably won’t for a couple more years. Some say the pioneers are the ones with arrows in their backs, and this is why a lot of CIO's are letting their peers forge into the Cloud before they are. Cloud is inevitable, it is certainly they direction our industry is moving; it's just moving a little slower than some predicted.
• It’s hard to see eye to eye when you can’t see face to face. I believe it was Hilton Hotel’s marketing program that launched that slogan. And it’s too often true. There is too much human element in IT projects that cannot be accomplished through teleconferences, online collaboration, email, or other non-human mediums. It reminds me of the "Jay Cutler Conference Call Fiasco" that any Bronco's fan remembers. You have to meet people in person, and that is why there are so many consulting road warriors out there.
• Think about it…how many of these initiatives can be successfully completed without face to face meetings: Requirements Management, Project Management, Enterprise Architecture, Governance, Technology Insertion, Portfolio Management, Program Management, Communication Management
• Off shoring of Operations, Maintenance, Sustainability, Support, and Administration to me makes a lot of sense. However, off shoring innovation, business requirements, prototypes, and new ideas to me seems risky. I’ve always claimed off shoring is a delicate balance of quality vs. cost and anyone who has been on an offshore team knows how well the product or deliverable needs to be specified before handing over to the offshore team to develop it. Also, I've experienced off-shoring may be cheaper, but it's also slower so anything that is requiring rapid market penetration, flexibility to change on the fly, or time sensitive may not be the best candidate for this model.
Ultimately, we will see minor shifts to more cloudsourcing type models, but certainly no wholesale shifts. Small and Medium sized businesses are prime candidates and are already beginning to embrace this model. It makes sense for them. It just doesn't make sense for the typical Fortune 2000 corporate culture, especially for their strategic initiatives. Don't get me wrong-- I'd like to see the model work and spend less time in airports myself, I just don't think corporate culture is ready for such a monumental shift in consulting models anytime soon.
Subscribe to:
Posts (Atom)