If Architects spent as much time building as they do arguing (debating), wonder if there would be more usable applications?
Governance Architects: Paid "No-men".
There are no such things as bad applications, just bad architects.
An architect's ego is often bigger than their architecture.
Fixing a bad software architecture is like getting over a sunburn-- lots of peeling, head scratching, and eventually reproducing from the beginning.
Enterprise Architects preach that technology is not the solution, but they use technology every day, hour, and minute. I find that ironic.
Don't let 1 bad software bug spoil the pot.
The biggest communication gap I see with architects is their failure to communicate that the architecture can change. It can, and most likely will! It's not a matter of "IF", its a matter of "when" change occurs.
We often compare software architecture to building a house. How many houses do you know can change their infrastructure rapidly? Maybe a bad example to compare physical world to virtual world?
How many Architects want to be like The Architect in the Matrix? I do. He is THE architect.
Speaking of Matrix, seems the Oracle beat the Architect in the final chapter of the Matrix Trilogy. Technology can win.
Whens the last time an Architect said "Good Job", "Thank You", "You're right", or "damn, you are just smarter than me..."
Tuesday, May 3, 2011
Monday, April 18, 2011
The Essential Cloud Integration Checklist
With the current paradigm shift towards cloud computing, it’s evident many companies are optimistically investing in cloud solutions. While some corporations are starting their private cloud infrastructure, other early adopters are driving out applications by developing directly in public cloud platforms, and even more are procuring software capabilities from the litany of Software as a Service (SaaS) vendors. No matter what your level of “Cloud Maturity” is or which deployment models you choose (SaaS, PaaS, or IaaS), there are certain essential architectural considerations when designing cloud environments. This is especially true for companies sharing information from their corporate applications into the cloud and vice versa-integrating existing systems with the cloud can be a daunting task. Sharing information with the cloud seems to be a concern for many CIO’s, since they haven’t established a level of trust with their cloud yet. This article explores the more critical characteristics of integrating to and from the cloud, and how to ensure your solution is stable, scalable, and interoperable. Consider this your Essential Cloud Integration Checklist.
(1) Security
Security is by far the #1 concern of IT departments when considering venturing into the cloud. Most of IT’s concern centers around the fear of exposing private or sensitive information to non-validated users. Nobody wants to be the next company featured on CNN for losing their customer’s data to an outside intruder. However, many of these same doubters would be surprised to learn that most Cloud providers have hosting and data centers that are far more secure than their own company’s on premise center. Overcoming the risk of losing sensitive data is best accomplished through education, cloud provider research, and contractual stipulations. In other words, make sure your cloud provider follows certain standards (some of which are outlined below), ensure you have the proper service level agreements to protect your company in case the cloud has a failure, and educate any doubters to cloud’s security capabilities. Standards such as Secure Socket Layers (SSL), Security Assertion Markup Language (SAML), and for encryption, authentication, and single-sign on (SSO) should be considered for any Cloud security architecture.
Cloud is based on a best-of-breed approach, and it’s common for companies to be tied in to multiple cloud vendors for their cloud solutions. If you buy-into a multiple cloud provider approach, how do you go about managing users logging into each provider’s proprietary, distributed, and multi-technology environments? This can become even more difficult when the cloud is off premise or a public Cloud. Policy Assertion standards such as Security Assertion Markup Language (SAML) will allow your systems to integrate via a single-sign on token and share security policies across technologies. This assumes your cloud provider supports SAML, which is an important consideration. Without direct SAML support, secondary options can be custom-based session tokens through cross-reference tables.
It’s also important to ensure your cloud provider supports SSL and other encryption techniques in case any sensitive Data needs to be exchanged with the cloud. This is especially true with public clouds, where the data can be crossing a public wire as it flows to/from the cloud, and the data needs to be masked from any potential interceptor.
Access Control of software source control objects in the cloud is also important during design time or runtime-- objects, screens, and content artifacts should be protected to disallow any threats of viewing the source code, business rules, opportunity to change the configuration of an object, or running or executing the object by a disallowed user.
These security approaches become increasingly more important, since many cloud providers practice Multi-tenancy, which is the ability for providers to host multiple customers on a single resource. Examples could include your company’s assets being hosted on a shared server, database, and disk drive as your most feared competitor. The cloud provider is responsible for separation of concerns and ensuring nothing is compromised.
(2) Interoperability.
Sending information to/from the Cloud is an important consideration because the Cloud can be both an authoritative source of information and a consumer of existing on-premise enterprise information. This information can be process, data, or business centric, but is still required to integrate with the Cloud to complete a business process. Normally, this integration needs to be electronic, automated, and seamless, so, its important for the cloud to have Application Programming Interfaces (API’s) that are remotely accessible to other systems off the cloud (or on other clouds). These API’s provide the channel or method for sending information into the Cloud, pulling information out of the Cloud, pushing information out of the Cloud, or modifying information in the Cloud. The most common technique for integration is webServices that comply with the WS-standards, and specific industry standards. This will allow the organization to leverage services and comply with architecture styles such as Service Oriented Architecture (SOA) to share information across technologies and platforms.
(3) Presentation Layer:
Working with different Cloud vendors, especially SaaS vendors, means you will have to familiarize with each vendor’s proprietary User Interfaces (UI). This can be a daunting task and cause a lot of “swivel chair integration” for the end users who have to work in multiple UI’s across cloud applications. Instead of swiveling and hand-jamming information across multiple systems, the preferred approach is to create a universal look and feel application that provides the “single version of the truth”. This is best accomplished through approaches such as Composite Applications and Mash-ups that are design patterns that integrate disparate information sources into a single application screen or portal. This architecture has many benefits, such as: simplifying working environments, increasing end user efficiently, and protecting the business process from less human errors. However, this architecture design pattern is not always simple to implement, as it requires the Cloud vendor to expose information via a real-time remote API, preferably webServices. Other considerations include support for standards such as Web Services for Remote Portlets (WSRP), and Java Spec 168 (JSR 168) to embed remote content into the consuming portal screen.
(4) Federated Search:
With so much information sprinkled throughout the enterprise, it’s becoming increasingly more important for companies to provide features to catalog, index, and expose content for search in enterprise systems. The Cloud is an enterprise system and the information contained within must be searchable. How is this accomplished if the Cloud is off-premise? The simplest approach is for the Cloud vendor to index their own content and expose the searchable content via a remote webService API. This will allow companies to integrate the Cloud content with any pre-established searching software they have already standardized on and prevent end users from having to use multiple search boxes to find their information. Companies will then reap the benefit of “single box search”, as having to swivel between multiple search User Interface’s can be a frustrating experience to locating content and information. This concept is known as “Federated Search” since the content being searched can be hosted anywhere across the enterprise or the cloud, but the user doesn’t need to worry about that as the search design complexities are abstracted from them—they simply have simple search UI that allows them to find associated content.
(5) Functionality and Usability
Working with multiple Cloud vendors presents other unique challenges that include the functionality of the software, workflow capabilities, and performance management. For example, how do I maintain a low click stream across all Cloud providers when they have unique taxonomies and page wire frames? They have different click stream architectures. How do I have a Workflow process that spans across multiple Cloud providers—especially true if the Cloud providers each have their own proprietary workflow tools? There needs to be a “master workflow” state engine that can be a master process flow across systems and leveraging their individual workflow capabilities. How do I manage performance or identify bottlenecks across multiple providers? Ping-ponging packets between on-premise systems, public cloud, and private clouds can cause inefficient data flows that cause long wait times. Ultimately, the end-users will suffer from cloud systems that doesn’t account for moving data between corporate firewalls and cloud providers.
(6) Standards
Standards are important for enforcing consistency and simpler governance models. This is especially important when different technologies, approaches, and vendors are involved in a cloud system. It’s important to rely on standards such as WSRP, SAML, W-3 webServices and more to simplify the integration and management amongst your portfolio of cloud providers.
Leading Practices:
While integrating with the cloud presents itself with unique set challenges that include: off-premise hosting, federated and distributed location of cloud providers, reliance on providers for standard and technology support, cross-firewall integration, and potential performance issues, there have evolved some early leading practices.
• Use a Service Oriented approach for integrating to and from the cloud
• Attach contracts to each service for management, monitoring, and governance
• Leverage standards wherever possible
• Limit the number of network hops when possible
• Integrate through webServices or remote API’s
• Rely on native cloud provider Workflow tools, and implement cross-technology workflow when processes cross technologies
• Strive for consistent look and feel, click stream, and overall usability through webServices and standards
(1) Security
Security is by far the #1 concern of IT departments when considering venturing into the cloud. Most of IT’s concern centers around the fear of exposing private or sensitive information to non-validated users. Nobody wants to be the next company featured on CNN for losing their customer’s data to an outside intruder. However, many of these same doubters would be surprised to learn that most Cloud providers have hosting and data centers that are far more secure than their own company’s on premise center. Overcoming the risk of losing sensitive data is best accomplished through education, cloud provider research, and contractual stipulations. In other words, make sure your cloud provider follows certain standards (some of which are outlined below), ensure you have the proper service level agreements to protect your company in case the cloud has a failure, and educate any doubters to cloud’s security capabilities. Standards such as Secure Socket Layers (SSL), Security Assertion Markup Language (SAML), and for encryption, authentication, and single-sign on (SSO) should be considered for any Cloud security architecture.
Cloud is based on a best-of-breed approach, and it’s common for companies to be tied in to multiple cloud vendors for their cloud solutions. If you buy-into a multiple cloud provider approach, how do you go about managing users logging into each provider’s proprietary, distributed, and multi-technology environments? This can become even more difficult when the cloud is off premise or a public Cloud. Policy Assertion standards such as Security Assertion Markup Language (SAML) will allow your systems to integrate via a single-sign on token and share security policies across technologies. This assumes your cloud provider supports SAML, which is an important consideration. Without direct SAML support, secondary options can be custom-based session tokens through cross-reference tables.
It’s also important to ensure your cloud provider supports SSL and other encryption techniques in case any sensitive Data needs to be exchanged with the cloud. This is especially true with public clouds, where the data can be crossing a public wire as it flows to/from the cloud, and the data needs to be masked from any potential interceptor.
Access Control of software source control objects in the cloud is also important during design time or runtime-- objects, screens, and content artifacts should be protected to disallow any threats of viewing the source code, business rules, opportunity to change the configuration of an object, or running or executing the object by a disallowed user.
These security approaches become increasingly more important, since many cloud providers practice Multi-tenancy, which is the ability for providers to host multiple customers on a single resource. Examples could include your company’s assets being hosted on a shared server, database, and disk drive as your most feared competitor. The cloud provider is responsible for separation of concerns and ensuring nothing is compromised.
(2) Interoperability.
Sending information to/from the Cloud is an important consideration because the Cloud can be both an authoritative source of information and a consumer of existing on-premise enterprise information. This information can be process, data, or business centric, but is still required to integrate with the Cloud to complete a business process. Normally, this integration needs to be electronic, automated, and seamless, so, its important for the cloud to have Application Programming Interfaces (API’s) that are remotely accessible to other systems off the cloud (or on other clouds). These API’s provide the channel or method for sending information into the Cloud, pulling information out of the Cloud, pushing information out of the Cloud, or modifying information in the Cloud. The most common technique for integration is webServices that comply with the WS-standards, and specific industry standards. This will allow the organization to leverage services and comply with architecture styles such as Service Oriented Architecture (SOA) to share information across technologies and platforms.
(3) Presentation Layer:
Working with different Cloud vendors, especially SaaS vendors, means you will have to familiarize with each vendor’s proprietary User Interfaces (UI). This can be a daunting task and cause a lot of “swivel chair integration” for the end users who have to work in multiple UI’s across cloud applications. Instead of swiveling and hand-jamming information across multiple systems, the preferred approach is to create a universal look and feel application that provides the “single version of the truth”. This is best accomplished through approaches such as Composite Applications and Mash-ups that are design patterns that integrate disparate information sources into a single application screen or portal. This architecture has many benefits, such as: simplifying working environments, increasing end user efficiently, and protecting the business process from less human errors. However, this architecture design pattern is not always simple to implement, as it requires the Cloud vendor to expose information via a real-time remote API, preferably webServices. Other considerations include support for standards such as Web Services for Remote Portlets (WSRP), and Java Spec 168 (JSR 168) to embed remote content into the consuming portal screen.
(4) Federated Search:
With so much information sprinkled throughout the enterprise, it’s becoming increasingly more important for companies to provide features to catalog, index, and expose content for search in enterprise systems. The Cloud is an enterprise system and the information contained within must be searchable. How is this accomplished if the Cloud is off-premise? The simplest approach is for the Cloud vendor to index their own content and expose the searchable content via a remote webService API. This will allow companies to integrate the Cloud content with any pre-established searching software they have already standardized on and prevent end users from having to use multiple search boxes to find their information. Companies will then reap the benefit of “single box search”, as having to swivel between multiple search User Interface’s can be a frustrating experience to locating content and information. This concept is known as “Federated Search” since the content being searched can be hosted anywhere across the enterprise or the cloud, but the user doesn’t need to worry about that as the search design complexities are abstracted from them—they simply have simple search UI that allows them to find associated content.
(5) Functionality and Usability
Working with multiple Cloud vendors presents other unique challenges that include the functionality of the software, workflow capabilities, and performance management. For example, how do I maintain a low click stream across all Cloud providers when they have unique taxonomies and page wire frames? They have different click stream architectures. How do I have a Workflow process that spans across multiple Cloud providers—especially true if the Cloud providers each have their own proprietary workflow tools? There needs to be a “master workflow” state engine that can be a master process flow across systems and leveraging their individual workflow capabilities. How do I manage performance or identify bottlenecks across multiple providers? Ping-ponging packets between on-premise systems, public cloud, and private clouds can cause inefficient data flows that cause long wait times. Ultimately, the end-users will suffer from cloud systems that doesn’t account for moving data between corporate firewalls and cloud providers.
(6) Standards
Standards are important for enforcing consistency and simpler governance models. This is especially important when different technologies, approaches, and vendors are involved in a cloud system. It’s important to rely on standards such as WSRP, SAML, W-3 webServices and more to simplify the integration and management amongst your portfolio of cloud providers.
Leading Practices:
While integrating with the cloud presents itself with unique set challenges that include: off-premise hosting, federated and distributed location of cloud providers, reliance on providers for standard and technology support, cross-firewall integration, and potential performance issues, there have evolved some early leading practices.
• Use a Service Oriented approach for integrating to and from the cloud
• Attach contracts to each service for management, monitoring, and governance
• Leverage standards wherever possible
• Limit the number of network hops when possible
• Integrate through webServices or remote API’s
• Rely on native cloud provider Workflow tools, and implement cross-technology workflow when processes cross technologies
• Strive for consistent look and feel, click stream, and overall usability through webServices and standards
Monday, March 28, 2011
IT Isn't Dead. 100% Guaranteed Approach to Keep your CEO Happy
If there is one constant with IT, it is the guarantee of change. Whether its new regulations, corporate leadership, changing business models, regulation and legislation, upcoming technologies, customer demands, changing marketplaces and global conditions, or company re-organization, there are many pressures on today’s modern IT department to always adapt to these latest changes to keep the business functioning and properly positioned. With the added pressure of the recent economic downturns, IT is being asked to deliver the same or more solutions, with less capital funding. The risks to companies following such an approach are glaringly obvious—do they sacrifice quality for agility? Do they comply with regulations sooner rather than later? Do they change their systems based on market conditions? All these aspects combined, can easily cause heartburn to today’s CEO’s. So, how do you keep your CEO (and CIO) happy and more importantly keep them employed? By following an application modernization strategy and approach, your IT department will remain ahead of the always changing curve, with a low risk profile, and be fully prepared for future-proofing your IT solutions.
Adoption of the internet has caused frenzied investment in new business ideas creating rapid advancement in technology, services, and standards. This is driving wide spread adoption of web-based technologies resulting in existing technology becoming outdated and software lifecycles becoming shorter. This leads to constant fluctuation in IT trends, many of which must be adopted to remain competitive with your organization’s business goals and to respond to the changes aforementioned. What are the IT trends of today that will dictate a company’s success? Do they require every IT department’s attention? Do they add value to the organization? Listed below are IT trends that every company should be considering in order to keep their company strategically aligned for high value gains:
• Cloud Computing: The ability to take commoditized assets off premise and follow a consumption cost model.
• System Consolidation: virtualizing and combining hardware, sun setting redundant systems, standardize on vendors.
• Enterprise Re-usability: Re-use and integrate existing assets, create single information sources, and sunset redundant systems.
• Mobile Solutions: Access business relevant information through mobile devices and perform business process remotely
• Portfolio Management: Manage and maintain corporate assets just like your stock portfolio; buy/sell in the marketplace through effective metrics.
• Technology Lifecycle Management: Manage vendor relationships, standards. Sunset technologies before workforce or vendor support become scarce or costly
• Off-shore management: manage cost-effective off-shore teams for effective and quality-driven results.
• Agile Methodologies: Follow an incremental approach that has rapid, value-driven milestones
• Technology Selection: Embrace open standards and technologies that are mature and sustainable.
There are many drivers to adopting such leading edge IT initiatives, some of which include the following: vendor drops support of products or technologies, modern skilled workforce and lack of legacy skilled professionals, new software programming languages, competitive pressures, and more. These all lead to following constant modernization and rationalization process that continuously re-evaluates the technologies, products, and corporate assets. By following a modernization strategy, that includes identifying application profiles for each corporate IT asset, will allow organizations to measure, monitor, and target their future IT portfolio. Having a continuous rationalization process through source selection techniques, will benefit companies looking for not only continuous improvement, but continuous optimization. This includes defining a prioritization framework so that each initiative can be ranked and selected based on the value it brings to the organization. Once such levels of maturity are achieved, organizations reap the ultimate benefit—re-allocating funding from maintenance-type initiatives to innovation-type initiatives. Re-focus IT from managing the day-to-day operations, to helping the business solve real business problems. This is often accomplished through a centralized, integrated, flexible framework that has been through the rigor of business case justification, performance and risk management, and strategy drivers.
Studies have shown that world-class companies have reaped the benefit of such initiatives: firms with world-class performance management outperform their peers by 240% (The Hacket Group), 404% ROI for customers leveraging SaaS delivery models (IDC), and 150% ROI for Grid customers (Mainstay Partners). These are figures to keep your CEO happy and are accomplishable by following a structured approach that stresses standardization, rapid value, vendor management, and commoditization of tactical and non-strategic functions.
Adoption of the internet has caused frenzied investment in new business ideas creating rapid advancement in technology, services, and standards. This is driving wide spread adoption of web-based technologies resulting in existing technology becoming outdated and software lifecycles becoming shorter. This leads to constant fluctuation in IT trends, many of which must be adopted to remain competitive with your organization’s business goals and to respond to the changes aforementioned. What are the IT trends of today that will dictate a company’s success? Do they require every IT department’s attention? Do they add value to the organization? Listed below are IT trends that every company should be considering in order to keep their company strategically aligned for high value gains:
• Cloud Computing: The ability to take commoditized assets off premise and follow a consumption cost model.
• System Consolidation: virtualizing and combining hardware, sun setting redundant systems, standardize on vendors.
• Enterprise Re-usability: Re-use and integrate existing assets, create single information sources, and sunset redundant systems.
• Mobile Solutions: Access business relevant information through mobile devices and perform business process remotely
• Portfolio Management: Manage and maintain corporate assets just like your stock portfolio; buy/sell in the marketplace through effective metrics.
• Technology Lifecycle Management: Manage vendor relationships, standards. Sunset technologies before workforce or vendor support become scarce or costly
• Off-shore management: manage cost-effective off-shore teams for effective and quality-driven results.
• Agile Methodologies: Follow an incremental approach that has rapid, value-driven milestones
• Technology Selection: Embrace open standards and technologies that are mature and sustainable.
There are many drivers to adopting such leading edge IT initiatives, some of which include the following: vendor drops support of products or technologies, modern skilled workforce and lack of legacy skilled professionals, new software programming languages, competitive pressures, and more. These all lead to following constant modernization and rationalization process that continuously re-evaluates the technologies, products, and corporate assets. By following a modernization strategy, that includes identifying application profiles for each corporate IT asset, will allow organizations to measure, monitor, and target their future IT portfolio. Having a continuous rationalization process through source selection techniques, will benefit companies looking for not only continuous improvement, but continuous optimization. This includes defining a prioritization framework so that each initiative can be ranked and selected based on the value it brings to the organization. Once such levels of maturity are achieved, organizations reap the ultimate benefit—re-allocating funding from maintenance-type initiatives to innovation-type initiatives. Re-focus IT from managing the day-to-day operations, to helping the business solve real business problems. This is often accomplished through a centralized, integrated, flexible framework that has been through the rigor of business case justification, performance and risk management, and strategy drivers.
Studies have shown that world-class companies have reaped the benefit of such initiatives: firms with world-class performance management outperform their peers by 240% (The Hacket Group), 404% ROI for customers leveraging SaaS delivery models (IDC), and 150% ROI for Grid customers (Mainstay Partners). These are figures to keep your CEO happy and are accomplishable by following a structured approach that stresses standardization, rapid value, vendor management, and commoditization of tactical and non-strategic functions.
Friday, March 25, 2011
Mobile Computing Primer for IT Developers
With over 5 billion mobile users worldwide, it’s clear that mobile applications are the cornerstone of our daily lives. Applications range from productivity tools to entertainment and games, and the usage of day-to-day applications is continually evolving with the influence of technology and cultural shifts. For example, certain technological achievements have enabled us to do more with our phones each year. Recent technological achievements include: greater mobile data bandwidth, Cloud Computing, feature-rich Smartphone devices, and adoption of ever improving industry standards. These technology enablers have provided the platform for mobile cultural shifts that include: use of social networks through mobile devices, increased use of text messaging, and more use of mobile cameras in unique ways (streaming video, barcode scanner).
Even though 93% of Americans have a mobile phone, there are still many unique challenges that exist when developing mobile applications, especially when designing for the expectations of today’s consumer. Today’s user is unlike the computer user of yesterday--multitasking is a way of life, typing is preferred over handwriting, staying connected is essential, zero tolerance for device delays, and the lines between consumer and creator are blurring. There are some interesting constraints in mobile computing that haven’t presented themselves in User Interface development for a long time, going back to the advent of the common desktop monitor when UI developers had to pay attention to screen size, memory usage, and limited disk space. Mobile computing constraints include: maintaining awareness of a limited screen size, allocating and releasing memory for devices with limited memory (for the time being, until mobile devices are equipped with larger memory capacity), security concerns with mobility, accessibility, and potential to lose a phone easily; and accounting for precision of the user (i.e. fat fingers punching small keys). These limitations can also be coupled with the realization that even more challenges exist when you factor in the number of device platforms, programming languages, adoption of the tablet device with unique parameters, wireless carrier contracts and exclusivities, incompatible radio frequencies across devices, and demand for backwards compatibility. Conclusion: developing mobile applications is not necessarily as easy as it looks.
The good news is that there are a plethora of tools, frameworks, and platforms to help us develop applications and streamline some of the more tactical aspects of development that often requires a lot of plumbing. Most development environments are cloud-based so that users don’t need to stand up the infrastructure in-house to develop applications. Most platforms have a standard development kit (SDK), emulator tools, and configurable attributes so that development and unit testing can be accomplished without even owning a mobile device or having a certain carrier’s plan. Coupled this with some of the more mature integration and interoperability tools available on the market, including Oracle ADF, Rho Mobile, and Oracle Mobile Framework to allow cross-platform and enterprise system integration. These provide framework building blocks that include: launching and displaying applications, displaying controls, responding to user actions, accessing the Internet, managing user preferences, playing sounds and videos, and much more.
There are some leading practices to mobile development. These can range from providing end users immediate feedback to their action (such as highlighting the item they selected), making applications forgiving to account for fat fingers, and to always follow the KISS philosophy (Keep it Simple Stupid). The economics of developing an application are very compelling, since a developer is on average entitled to a 70% fund of what is sold in the platforms application store, free promotion in the application store and community, and the low barriers to entry for getting started.
With nearly 70% of the Fortune 500 having budgeted plans to launch mobile solutions for their enterprise, it only makes sense for today’s IT developer to spend time learning and adjusting to the nuances of architecting, designing, and building mobile applications.
Even though 93% of Americans have a mobile phone, there are still many unique challenges that exist when developing mobile applications, especially when designing for the expectations of today’s consumer. Today’s user is unlike the computer user of yesterday--multitasking is a way of life, typing is preferred over handwriting, staying connected is essential, zero tolerance for device delays, and the lines between consumer and creator are blurring. There are some interesting constraints in mobile computing that haven’t presented themselves in User Interface development for a long time, going back to the advent of the common desktop monitor when UI developers had to pay attention to screen size, memory usage, and limited disk space. Mobile computing constraints include: maintaining awareness of a limited screen size, allocating and releasing memory for devices with limited memory (for the time being, until mobile devices are equipped with larger memory capacity), security concerns with mobility, accessibility, and potential to lose a phone easily; and accounting for precision of the user (i.e. fat fingers punching small keys). These limitations can also be coupled with the realization that even more challenges exist when you factor in the number of device platforms, programming languages, adoption of the tablet device with unique parameters, wireless carrier contracts and exclusivities, incompatible radio frequencies across devices, and demand for backwards compatibility. Conclusion: developing mobile applications is not necessarily as easy as it looks.
The good news is that there are a plethora of tools, frameworks, and platforms to help us develop applications and streamline some of the more tactical aspects of development that often requires a lot of plumbing. Most development environments are cloud-based so that users don’t need to stand up the infrastructure in-house to develop applications. Most platforms have a standard development kit (SDK), emulator tools, and configurable attributes so that development and unit testing can be accomplished without even owning a mobile device or having a certain carrier’s plan. Coupled this with some of the more mature integration and interoperability tools available on the market, including Oracle ADF, Rho Mobile, and Oracle Mobile Framework to allow cross-platform and enterprise system integration. These provide framework building blocks that include: launching and displaying applications, displaying controls, responding to user actions, accessing the Internet, managing user preferences, playing sounds and videos, and much more.
There are some leading practices to mobile development. These can range from providing end users immediate feedback to their action (such as highlighting the item they selected), making applications forgiving to account for fat fingers, and to always follow the KISS philosophy (Keep it Simple Stupid). The economics of developing an application are very compelling, since a developer is on average entitled to a 70% fund of what is sold in the platforms application store, free promotion in the application store and community, and the low barriers to entry for getting started.
With nearly 70% of the Fortune 500 having budgeted plans to launch mobile solutions for their enterprise, it only makes sense for today’s IT developer to spend time learning and adjusting to the nuances of architecting, designing, and building mobile applications.
Thursday, September 16, 2010
An Example of Agile Methodology, with a bit of a struggle
We are in the process of re-designing our website launch. The site will be based on Wordpress CMS, new content, new functionality, some revised branding, and new layouts. It's been a long time coming. I've been trying to think of an approach to launch the website iteratively so that its not contingent on a Big Bang launch and dependent on everything being done to launch. Unfortunately, I keep circling back to thinking that a partial launch of the site would diminsh our brand due to limiting the user experience. Therefore, I am currently aimng to launch with most of the requirements we've laid out for this project and not launch iteratively. Granted, some requirements can be de-prioritized for a future release, but the baseline site ("product") needs to be all (most all) or nothing for now. Now, this can all be bundled into a "Release", and requirements ("User Stories") tackled in a Sprint like fashion, but ultimately the struggle was in producing a finished product within a Sprint...that I didn't feel comfortable with, as we only have 5-7 seconds to grab a User's attention on your site, and a site that isn't 100% ready would lose the user pretty quickly. So, a bit of a struggle on applying Agile principles to a Released product in this situation.
Tuesday, August 31, 2010
Why I attend Oracle Open World
We live in a complex world. A world that is constantly changing. Businesses need to be able to adapt and evolve, rapidly, or face the consequences of failure. How do companies keep up with new customer demands, evolving business processes, new legislation, industry regulations and compliance, and business channels fueled by the Internet, and more? How do organizations protect against the risk of failure? We attend Oracle Open World, a forum to collaborate with peers, industry advisors, and leading experts on how to create and leverage solutions to solve complex business problems. Providing attendees contribute their expertise, knowledge power, intellectual capital, demonstrations, and leading practices so that other organizations have not only a proof point, but a roadmap to success. Others attend to learn, collaborate, network, and inquire how to design their solutions appropriately. It is a melting pot or ideas, solutions, and approaches for everyone to leverage. Opportunities abound to discuss the best businesses use of Oracles technology, so we can be more agile, flexible, and dynamic to meet the business challenges of today-- and address the unforeseen issues of tomorrow. Decisions will be made at Open World that will impact many organizations—product direction, architecture, and best use of technology. It’s important to remember that in today’s technology marketplace, we have many choices, and we have to be careful that we select, design, and implement the right platforms that will provide the appropriate solutions for our business—we must be equipped for success. Technology decisions come with risks that include stability, scalability, agility, performance, and meeting business expectations. No company can afford to make the wrong technology decisions, and this is why Open World is so important. Attendees can count on Oracle Open World to provide the proper insight, approach, and products to not only mitigate risks, but provide a roadmap to success.
Wednesday, August 25, 2010
To Agile or not Agile, that is the question
Following are the principles of Agile I like to incorporate into projects:
• Organizing phases into 2-4 week iterations (Sprints) so that there is distinct product or deliverable assigned to each iteration.
• Performing User Acceptance Testing (UAT) early in the system life cycle, rather than the end of the SDLC, to gather business user feedback early and often.
• Designing the system with the expectation of change. This allows agility and flexibility. I assume that the services we build will need to be dynamic with the changing business climate and will need rapid.
• Maintaining an On-going "Product Backlog" which is ranked and prioritized list of requirements. The list is constantly re-ranked and prioritized and the top candidates are inputs into the next Sprint iteration.
• Brief daily Status meetings (Scrum) to check progress, roadblocks, and planned activities.
• Collaboration amongst the team and amongst the business team is key to vetting solid and practical frameworks
• Keep it Simple. Making governance frameworks and patterns overly complex runs the risk of limiting adoption
• Business Processes are the foundation of what applications have as an objective, and in Agile the business stakeholders are a key to driving the development process (having a Product Owner).
• Governance requires Multi-stakeholder team, consisting of representation from various IT and business teams.
• The use of a Burn Down Chart can help all stakeholders track progress of the overall initiatives.
• Rapid. Using Agile will force teams to get working services and deliverables in a quicker fashion and forces accountability across the team.. This also has a good impact to team morale (developers tend to enjoy the Agile process)
• Good for creating a Knowledge base to capture "lessons learned" early and often for continuous improvement.
• Agile reduces waste; Captures bugs early, avoids goldplating, committed team members
Some of the more radical Agile principles that I don't necessarily prescribe or apply include:
• Limitation of documentation. In projects, especially around governance, certain documentation is key such as patterns, SLA's, contracts, frameworks, etc
• Self-organizing teams. I feel that leaving the teams to self-organize can be a bit optimistic and instead I feel a project sponsor is best suited to help organize the team, with our strategic input on personnel skills and capabilities.
• Documenting User Stories (Requirements) on stick notes. While this is good for collaborative working group sessions, I find it is very important to electronically capture and publish the User Stories for all team members to view through an online, browser enabled tool
• Individual iterations over processes and tools. I feel its important to follow a disciplined process and using the right tools to build services and applications is important as well.
• Not following a plan. I feel it is important to have a high level Roadmap for tackling projects, and maturity model that outlines milestones to achieve adoption and capability achievement.
• Organizing phases into 2-4 week iterations (Sprints) so that there is distinct product or deliverable assigned to each iteration.
• Performing User Acceptance Testing (UAT) early in the system life cycle, rather than the end of the SDLC, to gather business user feedback early and often.
• Designing the system with the expectation of change. This allows agility and flexibility. I assume that the services we build will need to be dynamic with the changing business climate and will need rapid.
• Maintaining an On-going "Product Backlog" which is ranked and prioritized list of requirements. The list is constantly re-ranked and prioritized and the top candidates are inputs into the next Sprint iteration.
• Brief daily Status meetings (Scrum) to check progress, roadblocks, and planned activities.
• Collaboration amongst the team and amongst the business team is key to vetting solid and practical frameworks
• Keep it Simple. Making governance frameworks and patterns overly complex runs the risk of limiting adoption
• Business Processes are the foundation of what applications have as an objective, and in Agile the business stakeholders are a key to driving the development process (having a Product Owner).
• Governance requires Multi-stakeholder team, consisting of representation from various IT and business teams.
• The use of a Burn Down Chart can help all stakeholders track progress of the overall initiatives.
• Rapid. Using Agile will force teams to get working services and deliverables in a quicker fashion and forces accountability across the team.. This also has a good impact to team morale (developers tend to enjoy the Agile process)
• Good for creating a Knowledge base to capture "lessons learned" early and often for continuous improvement.
• Agile reduces waste; Captures bugs early, avoids goldplating, committed team members
Some of the more radical Agile principles that I don't necessarily prescribe or apply include:
• Limitation of documentation. In projects, especially around governance, certain documentation is key such as patterns, SLA's, contracts, frameworks, etc
• Self-organizing teams. I feel that leaving the teams to self-organize can be a bit optimistic and instead I feel a project sponsor is best suited to help organize the team, with our strategic input on personnel skills and capabilities.
• Documenting User Stories (Requirements) on stick notes. While this is good for collaborative working group sessions, I find it is very important to electronically capture and publish the User Stories for all team members to view through an online, browser enabled tool
• Individual iterations over processes and tools. I feel its important to follow a disciplined process and using the right tools to build services and applications is important as well.
• Not following a plan. I feel it is important to have a high level Roadmap for tackling projects, and maturity model that outlines milestones to achieve adoption and capability achievement.
Thursday, August 19, 2010
Virtualization Support is the Elephant in the Cloud Room
Cloud Computing adoption is taking off. Two of the major principles of Cloud are: (1) resource pooling through mulitenancy (2)Elasticity. Multitenancy is the ability to have a single resource serves multiple clients. Example in Cloud is having multiple customers served by the same physical server. Elasticity is the ability to add or plug-in resources, fairly dynamically, to scale the server up or to scale down. For example, swapping in CPU, memory, disk space, etc.
Both of these principles are reliant on virtualization, the ability to run multiple, independent instances of software or hardware within a resource that was originally designed for a single use. The best example is a Server hosting multiple, independent operating systems that each are performing seperatlely from each other.
The leading vendor in the virtualization space is clearly VmWare. VmWare has been around the longest, and has the greatest market footprint, and has the most efficient use of hypervisor. Challengers in virtulaization space include Oracle, Microsoft, and few others.
The problem with VmWare, or the elephant in the room to speak of, is the # of enterprise software products that are still not supported on VmWare, namely Oracle. The largest example is Oracle, since they are the leader in enterprise software. Oracle software is only supported on Oracle's own product-- Oracle VM. Now, I do know there are a lot of customers running Oracle databases and Oracle middleware on VmWare and haven't had any issues yet. But, if there is an issue, these customers must understand their environment configured with VmWare is not supported by Oracle, Inc. You will be required to reproduce your issue in a non-VmWare environment OR on Oracle's VM software to get bug and issue support. This is scary, especially the number of customers I know who run Oracle on VmWare. Just the sheer possibility of losing production data or having long system downtime due to a non support issue, and then having to reproduce the entire environment to get support is enough risk for me take a strong look at Oracle VM so not to impact my Production systems. However, I'm no dummy and realize a lot of customers are running on VmWare just fine and haven't seen any issues, yet. I'd ask how advanced or complex their environement is? Are they doing RAC, Clustering, Load Balancing, Data Replication, or other advanced configurations? All of these could add complexity and impact the environment on a virtualization architecture. High performing applications that require this level of configuration could be risky in a VmWare environment, especially since VmWare does its own version of memory management, throwing off software like Oracle that manages its own SGA and PGA structures. Huge considerations for any customer thinking about virutalization-- lack of vendor support is serious stuff even if you think it works ok.
A second consideration is cost savings. This is one of the main drivers for virtualization. Squeeze more out of my existing resources instead of using it for a single purpose. For example, if I buy a physical server and its CPU and memory is very underutilized, then I can virtualize more Operating Systems onto the server and use the server for multiple purposes. This is good for hardware savings and not having to procure more hardware for your software applications, but won't buy you anything with your software licensing savings. the large software companies are very aware of this, and they will not give you a break on your software for putting more on a single resource. This is why they will not allow tools like VmWare to emulate the CPU's to make the customer's licensing less expensive.
I know VmWare has lots of examples where software on their product runs issue-free. This is great and I applaud the fact that it should work ok in a basic configured environement. However, VmWare cannot control the other software vendors like Oracle. I would ask to please get Oracle products officially supported on VmWare, and then we can all rest easier at night.
So, Big Elephant in the room-- to VmWare or not VmWare? No virtualziation, clearly makes a "Cloud Environment" difficult to achieve, especially losing multitenancy and elasticity principles. So, your first option is to ask your vendor what their policy is on virtualization support. If its a company like Oracle, consider using their Oracle VM product if you still need virutalization. VmWare may be your corporate standard for virtualization, but its not supported, and that is enough risk to avoid it until it is fully supported.
Both of these principles are reliant on virtualization, the ability to run multiple, independent instances of software or hardware within a resource that was originally designed for a single use. The best example is a Server hosting multiple, independent operating systems that each are performing seperatlely from each other.
The leading vendor in the virtualization space is clearly VmWare. VmWare has been around the longest, and has the greatest market footprint, and has the most efficient use of hypervisor. Challengers in virtulaization space include Oracle, Microsoft, and few others.
The problem with VmWare, or the elephant in the room to speak of, is the # of enterprise software products that are still not supported on VmWare, namely Oracle. The largest example is Oracle, since they are the leader in enterprise software. Oracle software is only supported on Oracle's own product-- Oracle VM. Now, I do know there are a lot of customers running Oracle databases and Oracle middleware on VmWare and haven't had any issues yet. But, if there is an issue, these customers must understand their environment configured with VmWare is not supported by Oracle, Inc. You will be required to reproduce your issue in a non-VmWare environment OR on Oracle's VM software to get bug and issue support. This is scary, especially the number of customers I know who run Oracle on VmWare. Just the sheer possibility of losing production data or having long system downtime due to a non support issue, and then having to reproduce the entire environment to get support is enough risk for me take a strong look at Oracle VM so not to impact my Production systems. However, I'm no dummy and realize a lot of customers are running on VmWare just fine and haven't seen any issues, yet. I'd ask how advanced or complex their environement is? Are they doing RAC, Clustering, Load Balancing, Data Replication, or other advanced configurations? All of these could add complexity and impact the environment on a virtualization architecture. High performing applications that require this level of configuration could be risky in a VmWare environment, especially since VmWare does its own version of memory management, throwing off software like Oracle that manages its own SGA and PGA structures. Huge considerations for any customer thinking about virutalization-- lack of vendor support is serious stuff even if you think it works ok.
A second consideration is cost savings. This is one of the main drivers for virtualization. Squeeze more out of my existing resources instead of using it for a single purpose. For example, if I buy a physical server and its CPU and memory is very underutilized, then I can virtualize more Operating Systems onto the server and use the server for multiple purposes. This is good for hardware savings and not having to procure more hardware for your software applications, but won't buy you anything with your software licensing savings. the large software companies are very aware of this, and they will not give you a break on your software for putting more on a single resource. This is why they will not allow tools like VmWare to emulate the CPU's to make the customer's licensing less expensive.
I know VmWare has lots of examples where software on their product runs issue-free. This is great and I applaud the fact that it should work ok in a basic configured environement. However, VmWare cannot control the other software vendors like Oracle. I would ask to please get Oracle products officially supported on VmWare, and then we can all rest easier at night.
So, Big Elephant in the room-- to VmWare or not VmWare? No virtualziation, clearly makes a "Cloud Environment" difficult to achieve, especially losing multitenancy and elasticity principles. So, your first option is to ask your vendor what their policy is on virtualization support. If its a company like Oracle, consider using their Oracle VM product if you still need virutalization. VmWare may be your corporate standard for virtualization, but its not supported, and that is enough risk to avoid it until it is fully supported.
Monday, July 5, 2010
SOA Evangelism is still an Uphill Battle
I recently attended a conference, and was happy that I wasn't speaking so I could sit back and enjoy being an attendee only. The conference was focused at and attended mostly by technologists, lots of developers in the house! The conference also had an entire track dedicated to SOA over the 3 day event. I was so excited to see that a conference that wasn't dedicated to SOA or BPM had an entire track over the 3 days on SOA.
I started off the conference by attending the SOA sessions. Logic would tell me to go to other sessions-- ones that I was unfamiliar with, so I could learn more about areas I wasn't as entrenched in. But, I threw logic out the window, and had to start where my heart is and see what other practitioners have to say about their SOA experiences.
The SOA sessions were interesting to sit through, but I was really surprised and disappointed that these SOA sessions were poorly attended. At a conference that had over 1,000 attendees, the SOA sessions struggled to get 10 attendees per session, while other sessions were "standing room only". The few folks who did attend, were trying to learn SOA 101 and how to get started with SOA at their respective organizations.
Despite the low attendance and interest at the SOA sessions, I still took it upon myself to preach SOA to attendees I networked with throughout the entire conference-- whether it was lunch, booth conversation, breaks, or even evening social hour, I spoke the SOA gospel. I quickly realized that most folks I encountered, struggled with the fundamentals of SOA and the value proposition it brings to their architecture. The 2 main excuses I heard from attendees about not embarking on SOA were 1) SOA is overkill for their organization (they don't think they need it) 2) SOA adds more complexity to the architecture and environment and the last thing they need is more complexity. Through questioning and examples, I tried to prove that both these "excuses" were incorrect. However, when your at a conference and only have a few minutes to get your point across to someone you just met for the first time, it's difficult to fundamentally change people's minds. At a minimum, I am confident I planted a few deep seeds for folks to think about or read more about SOA when they return back to their organizations.
It seems SOA evangelism is an uphill battle. Most folks I meet are non-believers when I meet them and they need to be converted to SOA. They say IT beliefs are like a religion, so we know conversion can be a difficult endeavor. I am ok with this responsibility and wholehearteldy accept it. My preferred approach towards gaining SOA acceptance is to engage and prove value through a Proof of Concept. I feel this is the best way to show SOA benefits. It's also important to understand that SOA truly is a paradigm shift-- a new way of thinking in organizations. With SOA, applications and systems aren't managed as the primary asset; rather, the service is. A lot of folks struggle with this concept, especially since they have been working in a single paradigm and only understand systems and applications throughout their careers.
What's the solution to overcoming this uphill battle? Continuous education, evangelism, and making sure demonstratable value can be achieved through proof of concepts and prototypes. Show your colleagues the money! IT needs to accept SOA before you can bring it to the business teams, so make sure you don't ignore the developers in your organization-- they are important stakeholders that need to be part of the SOA Journey from the beginning stages. Show them the light, and live by the motto "If you build it, they will come"!
I started off the conference by attending the SOA sessions. Logic would tell me to go to other sessions-- ones that I was unfamiliar with, so I could learn more about areas I wasn't as entrenched in. But, I threw logic out the window, and had to start where my heart is and see what other practitioners have to say about their SOA experiences.
The SOA sessions were interesting to sit through, but I was really surprised and disappointed that these SOA sessions were poorly attended. At a conference that had over 1,000 attendees, the SOA sessions struggled to get 10 attendees per session, while other sessions were "standing room only". The few folks who did attend, were trying to learn SOA 101 and how to get started with SOA at their respective organizations.
Despite the low attendance and interest at the SOA sessions, I still took it upon myself to preach SOA to attendees I networked with throughout the entire conference-- whether it was lunch, booth conversation, breaks, or even evening social hour, I spoke the SOA gospel. I quickly realized that most folks I encountered, struggled with the fundamentals of SOA and the value proposition it brings to their architecture. The 2 main excuses I heard from attendees about not embarking on SOA were 1) SOA is overkill for their organization (they don't think they need it) 2) SOA adds more complexity to the architecture and environment and the last thing they need is more complexity. Through questioning and examples, I tried to prove that both these "excuses" were incorrect. However, when your at a conference and only have a few minutes to get your point across to someone you just met for the first time, it's difficult to fundamentally change people's minds. At a minimum, I am confident I planted a few deep seeds for folks to think about or read more about SOA when they return back to their organizations.
It seems SOA evangelism is an uphill battle. Most folks I meet are non-believers when I meet them and they need to be converted to SOA. They say IT beliefs are like a religion, so we know conversion can be a difficult endeavor. I am ok with this responsibility and wholehearteldy accept it. My preferred approach towards gaining SOA acceptance is to engage and prove value through a Proof of Concept. I feel this is the best way to show SOA benefits. It's also important to understand that SOA truly is a paradigm shift-- a new way of thinking in organizations. With SOA, applications and systems aren't managed as the primary asset; rather, the service is. A lot of folks struggle with this concept, especially since they have been working in a single paradigm and only understand systems and applications throughout their careers.
What's the solution to overcoming this uphill battle? Continuous education, evangelism, and making sure demonstratable value can be achieved through proof of concepts and prototypes. Show your colleagues the money! IT needs to accept SOA before you can bring it to the business teams, so make sure you don't ignore the developers in your organization-- they are important stakeholders that need to be part of the SOA Journey from the beginning stages. Show them the light, and live by the motto "If you build it, they will come"!
Monday, June 21, 2010
Is Dynamic Endpoint Selection practical?
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?
-- 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?
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.
Monday, May 10, 2010
Are we Paid to Say No?
In a time when “yes we can” is the more popular battle cry, it seems software architects are still more aligned to turn down aspiring projects, due mostly to their roles as governance gatekeepers. This is not meant to criticize, as most enterprise-level software rejections are well scrutinized and evaluated before making such decisions. Software architects take their governance initiatives seriously, and I can say with a high level of confidence that most of these denials are highly justified. But, have we architects lost our entrepreneurial spirit, with governance as our defense? Are we over-scrutinizing new ideas and slowing down pilots of innovation because they don’t align with our governance policies and enterprise frameworks? Are we paid to say “no” more often then we say “yes”? How can we spearhead innovation instead of being too much of a police officer? The “Answer Lies Within”...
Look around
Where do you belong
Don't be afraid
You're not the only one
Don't let the day go by
Don't let it end
Don't let a day go by in doubt
The answer lies within
· Coach along projects you know are coming down the Pipeline instead of turning them back to the drawing board when it’s time to review them for acceptance (and therefore too late to help them…).
· Help seed projects from the early stages by proving mentoring at the beginning, not the end. In other words, become a venture capitalist of your organization by helping new software ideas align to governance early! Invest in the next enterprise “start-up”!
· Follow Agile Principles—do things earlier, not later in the lifecycle.
· Institute a Software Mentorship programs to benefit the organization. Being a champion without sharing your secrets to success is selfish. Help the greater good of the enterprise.
· Put governance in the backseat during the early stages of a pilot project. Help get prototypes off the ground by marginalizing governance (for the moment…). Some of the best innovations had to bend (or break) the rules. Be a game changer if you have to! Governance can always to adapted and applied at a later stage (not too late...), but don’t sacrifice innovation for indoctrination.
· Create a culture of excitement, encouragement, and positive attitude. If others think meeting with you is going to the Principal’s office that culture will limit and intimidate the organization. Nothing new will arise and instead creates a cultural bottleneck to the next “Big Idea”. Don’t be a bottleneck to new ideas…
Monday, March 29, 2010
Enterprise Architecture IS Arbitrary
Just finished reading Yes, “Enterprise Architecture Is Relative” BUT It Is Not Arbitrary"
and it was a nice article, but I politely disagree with Zman that "architecture is not arbitrary".
Lock 10 architects in 10 separate rooms; provide them all an identical copy of the same business, technical, process, and system requirements; have them design an architecture under the same rules and perspectives; and I guarantee your result will be 10 different architectures of varying degrees. Maybe my opinion is biased because I come from a Software background, but I often think Enterprise Architecture is an Art that is trying to apply a Science. No 2 architectures are identical. No 2 interpretations of how an Architecture should look like are identical. No 2 Architects think alike. Often times, Architecture is the art of compromise because rarely will you get to 2 architects to agree on the final architecture. Compromise is really hard for us, because we are traditionally very stubborn people! I've met many an architect whose ego is bigger than the Internet, and thinks he could teach a thing or 2 to Socrates. We don't like to be told we are wrong, especially when we develop a "work of art".
Maybe a better statement can be "architecture tries to make the design non arbitrary". With good architecture principles, patterns, frameworks, rules, constraints, standards, policies, procedures, and approach, the design becomes a simplistic exercise with little left to judgement, error, and becomes more a commoditized task. This is what I think architecture truly strives for-- making everything downstream trivial. Architecture lays the foundation for the remaining pieces to snap in very easily without much variance. Success is when the blueprint is followed according to plan!
The article continues to articulate how industry standards have played a role in making architecture non-arbitrary. This makes sense in certain vertical industries cited in the article such as airplane manufacturing, nuclear power plants, developing the Space Shuttle. However, it doesn't make sense in many commercial corporations whose architecture is centered and largely dependent on enterprise software .
Think about it-- Building an airplanes for Boeing or a nuclear reactor has very strict standards, specifications, and processes with little to no variance. However, building software has tons of variance and therefore industry standards are rarely adopted religiously in software implementation (unless you are in some thees industries mentioned above). There are some very simple reasons for this dynamic:
and it was a nice article, but I politely disagree with Zman that "architecture is not arbitrary".
Lock 10 architects in 10 separate rooms; provide them all an identical copy of the same business, technical, process, and system requirements; have them design an architecture under the same rules and perspectives; and I guarantee your result will be 10 different architectures of varying degrees. Maybe my opinion is biased because I come from a Software background, but I often think Enterprise Architecture is an Art that is trying to apply a Science. No 2 architectures are identical. No 2 interpretations of how an Architecture should look like are identical. No 2 Architects think alike. Often times, Architecture is the art of compromise because rarely will you get to 2 architects to agree on the final architecture. Compromise is really hard for us, because we are traditionally very stubborn people! I've met many an architect whose ego is bigger than the Internet, and thinks he could teach a thing or 2 to Socrates. We don't like to be told we are wrong, especially when we develop a "work of art".
Maybe a better statement can be "architecture tries to make the design non arbitrary". With good architecture principles, patterns, frameworks, rules, constraints, standards, policies, procedures, and approach, the design becomes a simplistic exercise with little left to judgement, error, and becomes more a commoditized task. This is what I think architecture truly strives for-- making everything downstream trivial. Architecture lays the foundation for the remaining pieces to snap in very easily without much variance. Success is when the blueprint is followed according to plan!
The article continues to articulate how industry standards have played a role in making architecture non-arbitrary. This makes sense in certain vertical industries cited in the article such as airplane manufacturing, nuclear power plants, developing the Space Shuttle. However, it doesn't make sense in many commercial corporations whose architecture is centered and largely dependent on enterprise software .
Think about it-- Building an airplanes for Boeing or a nuclear reactor has very strict standards, specifications, and processes with little to no variance. However, building software has tons of variance and therefore industry standards are rarely adopted religiously in software implementation (unless you are in some thees industries mentioned above). There are some very simple reasons for this dynamic:
- Qualifications for building software are low. Low barrier to entry, commoditized work force, easy to learn software programming skills.
- QA requirements are much lower. Often times, it's "just enough QA" and many corners are cut and sacrificed so not to slow down the market plan.
- Time to Market patience is low. Software is expected to get deployed before its truly ready (and bugs are well known). Rapid is the name of the game, especially in today's economy.
Sunday, March 28, 2010
Healthcare IT to benefit greatly from new Bill
Whether you are an elephant or donkey, something we can all agree on is that our health care system is currently not well-integrated from an Information Technology perspective. Health care is filled with expensive data redundancies, outdated and non-timely information, slow processes, and yes even bad and incorrect data. Well, if your in the business of integrating these systems, processes, and institutions, your in luck because the new health care bill is full of funding for electronic medical integration, and is said to "buoy last years $20M health care IT stimulus". Wow. Health care IT innovation may finally be getting its proverbial kick in the butt. This is a good article that provides a nice overview: http://tinyurl.com/yzzfp95 . If your in the market of integrating these systems, go hire a good proposal and grant writer because there will be a lot of opportunities to win business with the government. And, if we truly deliver on the promises of an efficient Health care system with Electronic Medical Records (EMR), we the citizens will benefit as well in having better visibility into our records, faster medical processing, less mistakes, reduced costs, etc. Healthcare IT has always lagged from its corporate peers in updating its IT systems, but now we can expect to see a lot of catch-up...the only question is at what cost? Maybe this is something Republicans and Democrats can agree on?
Monday, March 22, 2010
Healthcare Regulation requires Business Agility
Whether you agree with the US's recent bill on health care reform or not, it is clear that businesses will need to be agile in order to comply with the new forthcoming regulations they must comply with. There are always byproducts of regulation (i.e. secondary markets) and I have to think SOA will be one of the beneficiaries from organizations having to be flexible enough to comply with new regulations. How fast can a business change without disrupting current business operations and without impacting new growth opportunities? That is a scary question to many organizations and sends shivers down CIO's backs. A lot of organizations either don't have the IT flexibility to change with these new demands on their business, or can only adapt through manual, non-automated processes (such as hiring more business analysts to collect and disseminate the corporate information-- see "swivel chair integration"). They might be able to throw an army at the problem, but that is not only resource expensive, but risky in waiting until the problem bubbles to the top.
SOA is premised on the philosophy of "designing for change". The goal is that when business requirements change, IT can rapidly make adjustments to support the business demands because the IT systems are designed, documented, and impact transparent to allow IT to quickly adapt to new requirements. Businesses are always changing-- new business opportunities, new channels (see "Internet"), new partnerships, Mergers and Acquisitions, or in this case NEW REGULATION. The challenge is IT can't keep up with their current architecture and IT envirnements, let alone support all this change! Unfortunately, the whole company suffers from lack of agility! I would love to see a poll of Fortune 2,000 companies on how quickly their IT departments were able to adapt and change when Sarbanes Oxley regulations were enforced upon them? My bet is this would be measured in years, not months, and there are still quite a few companies struggling to adopt Sarbanes today.
Now that we know businesses will need to comply with new health care reporting, financing, personnel, operations, and taxes, how many are equipped to comply with the new reform? Will this be Sarbanes Part 2 and will IT departments be scrambling to change their tightly interwoven legacy systems, CIO's hiring more business analysts for more swivel chair integration, companies being fined for lack of compliance, or even worse making the front page of the Newspaper? How about more regulation coming down the pipe? If there is one constant we do know, is that the business will always change. Regulation is never a 1 and done initiative.
There will always be new regulations enacted on companies, so I advocate that businesses bite the bullet now and invest in agility by considering how SOA approaches can help them solve these problems, limit their impact from required changes, and prevent risk. The payoff from SOA investment will easily be achieved in this case, simply by reducing the cost of regulation compliance (lower resource cost) and "future proofing" the organiztion for adapting to new regulations on the horizon. Let's not forget, SOA-driven agility also opens doors for new revenue opportunities too-- another topic for another day. The early bird gets the worm, so be proactive instead of reactive by architecting your IT environment to meet these important business needs!
SOA is premised on the philosophy of "designing for change". The goal is that when business requirements change, IT can rapidly make adjustments to support the business demands because the IT systems are designed, documented, and impact transparent to allow IT to quickly adapt to new requirements. Businesses are always changing-- new business opportunities, new channels (see "Internet"), new partnerships, Mergers and Acquisitions, or in this case NEW REGULATION. The challenge is IT can't keep up with their current architecture and IT envirnements, let alone support all this change! Unfortunately, the whole company suffers from lack of agility! I would love to see a poll of Fortune 2,000 companies on how quickly their IT departments were able to adapt and change when Sarbanes Oxley regulations were enforced upon them? My bet is this would be measured in years, not months, and there are still quite a few companies struggling to adopt Sarbanes today.
Now that we know businesses will need to comply with new health care reporting, financing, personnel, operations, and taxes, how many are equipped to comply with the new reform? Will this be Sarbanes Part 2 and will IT departments be scrambling to change their tightly interwoven legacy systems, CIO's hiring more business analysts for more swivel chair integration, companies being fined for lack of compliance, or even worse making the front page of the Newspaper? How about more regulation coming down the pipe? If there is one constant we do know, is that the business will always change. Regulation is never a 1 and done initiative.
There will always be new regulations enacted on companies, so I advocate that businesses bite the bullet now and invest in agility by considering how SOA approaches can help them solve these problems, limit their impact from required changes, and prevent risk. The payoff from SOA investment will easily be achieved in this case, simply by reducing the cost of regulation compliance (lower resource cost) and "future proofing" the organiztion for adapting to new regulations on the horizon. Let's not forget, SOA-driven agility also opens doors for new revenue opportunities too-- another topic for another day. The early bird gets the worm, so be proactive instead of reactive by architecting your IT environment to meet these important business needs!
Tuesday, November 3, 2009
SOA Manifesto Value Statement Critique
Looks like the SOA Manifesto went public recently. I wasn’t invited to participate, so what does one do when not invited to a party? It’s quite obvious—you tell everyone how bad the party was, right? Ahh, High School memories revisited… Any case, I commend the community for coming together to vet through definitions, principles, and value statements (Heck, Even the SOA is Dead blogger was there, which I find really ironic.) However, I feel a few key points were missed and below are my critiques of the 6 value statements. Keep in mind that my critiques aren’t intended to poke holes in the value statements just due to my lack of involvement; rather, I truly found the value statement to be confusing, not accurate, and a few that are a lot broader than just SOA. I tried to put myself in the shoes of a SOA newbie who is using this to grasp SOA for the first time, and therefore felt obligated to point out areas that could use improvement. I truly hope this is constructive and maybe we see a 2nd version of the manifesto that incorporates this feedback (how Agile would that be?). Please call me and I’m more than willing to help. I love parties!
Value Statement Critique
#1 Business value over technical strategy. This was easily my favorite value statement. In my own Blog, I called it Business Visibility and Understanding over IT Priorities. Clearly, everyone must agree that our goal is to create business solutions. Conclusion: Great statement! The business does always come first! That’s why we’re here!
#2 Strategic goals over project-specific benefits. I am not sure I can agree with this value statement in the fact that I don’t always believe that strategic goals trump project specific benefits. My feeling is if you take this philosophy, you may never get your SOA project started or out of the gates. My rationale is that in order to get SOA funded and jumpstarted, you need to produce something that is demonstratable and appealing to the business, in a very rapid implementation. How else do you get initial buy-in? My feeling is that (1) this value statement is more academic than practical (2) this value statement is also a lot broader than just SOA…So I am compelled to proclaim, Isn't this what the original Agile manifesto is supposed to avoid-- academic principles that are difficult to follow in practice and too abstract to actually leverage?? I think there could have been a more SOA-specific statement in here, while this is more Enterprise Architecture, touchy-feely. Conclusion: I love the idea of everything being strategic (we don’t like tactical), but not sure this will statement work (especially in this economic climate!). Isn’t this what made SOA Dead? Now, do I think one should ignore strategy? No, there is certainly an overarching strategy and vision to work towards something greater and more holistic along the SOA Roadmap; however, I do think SOA needs to start from the ground-up to gain proper momentum and business-level buy-in and the only way to accomplish this is through incremental project implementations that have a discrete goal, are demonstrable, and appealing to the business.
# 3 Intrinsic interoperability over custom integration. I have mixed emotions on this value statement. I believe interoperability is one of the leading principles of SOA, but I also think it’s a bit confusing to have that value prioritized over "custom integration". I don’t think we are comparing Apples to Apples here. I think a better wording of this statement would have been "interoperability over individual silo's"...in my blog I stated "integrated systems, processes, and people over individual silo's". The problem with the "custom integration" wording in this statement is most legacy systems require custom integration in order to make them interoperable! Not everything is component-driven, plug and play or "configuration driven design", which to me are the opposite of "custom integration". I’ve seen a lot of custom integration in SOA, and it was required for the proper transformation of the system. Conclusion: I like the first part of the statement (Interoperability rules!), but find the second part to be inaccurate and confusing.
#4: Shared services over specific-purpose implementations. I do like the concept of Shared Services, as I find re-usability one of the leading principles in SOA. Again, I'm not in love with the 2nd half of this statement, as I'm not sure it is accurate. I feel very strongly that there are many specific-purpose objects in SOA architecture and required throughout the implementations and design. Not every service is going to be a Shared Service or a Business Service. For example, data services or IT services are usually very specific to the system they are interfacing with or rule they are enforcing. Take any data service that is part of the CRUD model on a legacy database—is that a shared service or a specific purpose implementation? Conclusion: I like the idea and whish everything could be reusable, but don’t want to undervalue services that are not!
#5 Flexibility over optimization. This statement gave me the most heartburn. Simply put, I don't agree with this statement. I believe flexibility and optimization are mutually exclusive and therefore one should not be valued over the other. How can you value one over the other? It’s been very clear to me that some services could be static but value optimization more than flexibility. For example,
A high speed transaction in a Financial Services business process would value optimization much more than flexibility. I feel a more appropriate wording of this statement would have been “Flexibility over rigor”. This I can agree with that agility and adaptability are leading principles. But, so is business process optimization. Let’s not forget software engineers, that there is always a trade-off of performance vs. agility in software programming and at the end of the day, some applications (and services) need more speed and acceleration over flexibility and agility. It is always a case-by-case basis. Conclusion: Misleading prioritization. Would really like to see this re-worded and re-released to clarify.
#6 Evolutionary refinement over pursuit of initial perfection I like this statement, as it enforces the iterative nature of "Agile lifecycle and management" and leads one to believe that an early feedback cycle will be incorporated. However, I have to ask, is this principle really specific to SOA? Isn't this just a re-hash of Agile Principle #12? Conclusion: Love this value statement, as I think iterative, early feedback is the way to go, but I think this statement applies to more than just SOA-- any project being implemented should follow this statement, and therefore I diminish the value of this statement only because I feel we heard this before in the Agile Manifesto.
Value Statement Critique
#1 Business value over technical strategy. This was easily my favorite value statement. In my own Blog, I called it Business Visibility and Understanding over IT Priorities. Clearly, everyone must agree that our goal is to create business solutions. Conclusion: Great statement! The business does always come first! That’s why we’re here!
#2 Strategic goals over project-specific benefits. I am not sure I can agree with this value statement in the fact that I don’t always believe that strategic goals trump project specific benefits. My feeling is if you take this philosophy, you may never get your SOA project started or out of the gates. My rationale is that in order to get SOA funded and jumpstarted, you need to produce something that is demonstratable and appealing to the business, in a very rapid implementation. How else do you get initial buy-in? My feeling is that (1) this value statement is more academic than practical (2) this value statement is also a lot broader than just SOA…So I am compelled to proclaim, Isn't this what the original Agile manifesto is supposed to avoid-- academic principles that are difficult to follow in practice and too abstract to actually leverage?? I think there could have been a more SOA-specific statement in here, while this is more Enterprise Architecture, touchy-feely. Conclusion: I love the idea of everything being strategic (we don’t like tactical), but not sure this will statement work (especially in this economic climate!). Isn’t this what made SOA Dead? Now, do I think one should ignore strategy? No, there is certainly an overarching strategy and vision to work towards something greater and more holistic along the SOA Roadmap; however, I do think SOA needs to start from the ground-up to gain proper momentum and business-level buy-in and the only way to accomplish this is through incremental project implementations that have a discrete goal, are demonstrable, and appealing to the business.
# 3 Intrinsic interoperability over custom integration. I have mixed emotions on this value statement. I believe interoperability is one of the leading principles of SOA, but I also think it’s a bit confusing to have that value prioritized over "custom integration". I don’t think we are comparing Apples to Apples here. I think a better wording of this statement would have been "interoperability over individual silo's"...in my blog I stated "integrated systems, processes, and people over individual silo's". The problem with the "custom integration" wording in this statement is most legacy systems require custom integration in order to make them interoperable! Not everything is component-driven, plug and play or "configuration driven design", which to me are the opposite of "custom integration". I’ve seen a lot of custom integration in SOA, and it was required for the proper transformation of the system. Conclusion: I like the first part of the statement (Interoperability rules!), but find the second part to be inaccurate and confusing.
#4: Shared services over specific-purpose implementations. I do like the concept of Shared Services, as I find re-usability one of the leading principles in SOA. Again, I'm not in love with the 2nd half of this statement, as I'm not sure it is accurate. I feel very strongly that there are many specific-purpose objects in SOA architecture and required throughout the implementations and design. Not every service is going to be a Shared Service or a Business Service. For example, data services or IT services are usually very specific to the system they are interfacing with or rule they are enforcing. Take any data service that is part of the CRUD model on a legacy database—is that a shared service or a specific purpose implementation? Conclusion: I like the idea and whish everything could be reusable, but don’t want to undervalue services that are not!
#5 Flexibility over optimization. This statement gave me the most heartburn. Simply put, I don't agree with this statement. I believe flexibility and optimization are mutually exclusive and therefore one should not be valued over the other. How can you value one over the other? It’s been very clear to me that some services could be static but value optimization more than flexibility. For example,
A high speed transaction in a Financial Services business process would value optimization much more than flexibility. I feel a more appropriate wording of this statement would have been “Flexibility over rigor”. This I can agree with that agility and adaptability are leading principles. But, so is business process optimization. Let’s not forget software engineers, that there is always a trade-off of performance vs. agility in software programming and at the end of the day, some applications (and services) need more speed and acceleration over flexibility and agility. It is always a case-by-case basis. Conclusion: Misleading prioritization. Would really like to see this re-worded and re-released to clarify.
#6 Evolutionary refinement over pursuit of initial perfection I like this statement, as it enforces the iterative nature of "Agile lifecycle and management" and leads one to believe that an early feedback cycle will be incorporated. However, I have to ask, is this principle really specific to SOA? Isn't this just a re-hash of Agile Principle #12? Conclusion: Love this value statement, as I think iterative, early feedback is the way to go, but I think this statement applies to more than just SOA-- any project being implemented should follow this statement, and therefore I diminish the value of this statement only because I feel we heard this before in the Agile Manifesto.
Monday, October 26, 2009
Flying in the Clouds requires many levels of TRUST
I have been fortunate to present introductory concepts and practices in Cloud Computing at 3 different conferences of late. The audience is very active, usually about 50 attendees in the room. However, it's very interesting that every time I poll the audience on who has used cloud services or a cloud provider, I usually get anywhere from 0-1 hands raised. It seems most folks are still feeling out cloud and a lot of it has to do with an overall lack of trust.
I receive a lot of questions on security and data ownership concerns throughout my presentations, but one in particular struck me as a great discussion point. Right when I was building confidence that I had all the answers to everything anyone wanted to know about Cloud, a question got asked that really got me thinking more about cloud and the requirement for TRUST. This particular person simply asked: “What do you do to prevent Cloud employees, particular Administrators with System level access, from jeopardizing or leaking your company’s sensitive information”? It’s a very pertinent question, and although there is no silver bullet solution, the answer ultimately relies on TRUST. If you are going to implement in the Cloud, you must have multiple levels of TRUST. After all, you’re putting protected (and potentially sensitive) company information in the hands of others, and that in itself takes a lot of TRUST. The answer to the questions asked-- you need to trust your provider just the same as you trust your employees (Do you trust your employees?) It's important to follow some of the practices below to help solidify trust in your cloud provider:
(1) Choose your cloud providing vendor wisely. If you don’t TRUST your cloud provider, then you won’t sleep at night. If data ownership and security will bother you to no avail, then you might not be ready for the cloud and using a provider. You must pick a vendor you TRUST to protect your must sensitive information. Do you TRUST your spouse? Yes, of course! This same level of TRUST must exist for your Cloud provider; otherwise you could be doomed for an early divorce. Make sure to meet your Cloud Provider face to face so that you know them well. Interview your Cloud provider. Interview your Cloud provider’s employees. Treat your provider’s employees it as if you’re hiring their employees, because they are now part of your “team”. You need to equally TRUST them as if they were your own, because the will have the same access and privileges. Make sure you have their contact info, background check results, and overall level of confidence from having met them face-to-face.
(2) Iron clad contracts. Template NDA’s are not sufficient for this new paradigm that cloud computing presents (using other people's assets). Your legal team may not be ready for cloud because legal doesn’t TRUST anyone...sorry legal! Talk to legal and explain the model, so that the contracts and non-disclosures provide adequate protection for the worst possible failure (such as sensitive data leak). This is your insurance plan, so make sure you cover your bases and have contractual stipulations to protect your cloud relationship.
(3) Stage an unannounced vulnerability test on your cloud provider. Similar to when TSA is testing airport security with their security tiger team, you can execute a mock infiltration test scenario without the cloud provider security team knowing its coming. This will help you establish the confidence and TRUST that your data and systems have the highest level of protection (unless, they fail the test…)
(4) Walk before you run. Try before you buy. Date before your marry. Don’t put the most mission critical systems or applications in the cloud until you have confidence, cultural acceptance, and level of comfort through a cloud pilot. Build the TRUST needed through incremental successes and then go for the big enchilada when you’ve reached an appropriate milestone-- i.e cloud tested, verified, and trusted.
(5) Ask for weekly or monthly performance reports that show how effective and secure the cloud provider is performing. Make them earn your TRUST through metrics , quantitative analysis, and statistics.
(6) Tour the facilities where your cloud provider will host your solution. Make sure they show you exactly where your space will be located. You need to see your hosting space in person to TRUST that will be adequate.
(7) Ask for reference qualifications. See if others TRUST the provider as well. Ask the references how they overcame their trust concerns (peer advice).
(8) Ensure there are Key Performance Indicators that are contractually tied to the performance. This includes incentives and disincentives on their Service Level Agreements. Make them perform to the level of TRUST they have committed to.
(9) Keep a contingency plan and contingency architecture in case things don’t work out in the cloud and you need to drop back to Earth. If the TRUST fails and the cloud fails, you need a back-up plan so you are not left without the infrastructure to deliver your business capabilities. Cloud is a new, so a contingency is very important.
(10) Consult with diverse set of stakeholders in your organization to get their "cloud advice". Talk with the SOA, EA, IT Architects, developers, business users to get their opinions and recommendations. Make sure a broad group is surveyed to ensure cloud decisions are not made in a vac cum.
I receive a lot of questions on security and data ownership concerns throughout my presentations, but one in particular struck me as a great discussion point. Right when I was building confidence that I had all the answers to everything anyone wanted to know about Cloud, a question got asked that really got me thinking more about cloud and the requirement for TRUST. This particular person simply asked: “What do you do to prevent Cloud employees, particular Administrators with System level access, from jeopardizing or leaking your company’s sensitive information”? It’s a very pertinent question, and although there is no silver bullet solution, the answer ultimately relies on TRUST. If you are going to implement in the Cloud, you must have multiple levels of TRUST. After all, you’re putting protected (and potentially sensitive) company information in the hands of others, and that in itself takes a lot of TRUST. The answer to the questions asked-- you need to trust your provider just the same as you trust your employees (Do you trust your employees?) It's important to follow some of the practices below to help solidify trust in your cloud provider:
(1) Choose your cloud providing vendor wisely. If you don’t TRUST your cloud provider, then you won’t sleep at night. If data ownership and security will bother you to no avail, then you might not be ready for the cloud and using a provider. You must pick a vendor you TRUST to protect your must sensitive information. Do you TRUST your spouse? Yes, of course! This same level of TRUST must exist for your Cloud provider; otherwise you could be doomed for an early divorce. Make sure to meet your Cloud Provider face to face so that you know them well. Interview your Cloud provider. Interview your Cloud provider’s employees. Treat your provider’s employees it as if you’re hiring their employees, because they are now part of your “team”. You need to equally TRUST them as if they were your own, because the will have the same access and privileges. Make sure you have their contact info, background check results, and overall level of confidence from having met them face-to-face.
(2) Iron clad contracts. Template NDA’s are not sufficient for this new paradigm that cloud computing presents (using other people's assets). Your legal team may not be ready for cloud because legal doesn’t TRUST anyone...sorry legal! Talk to legal and explain the model, so that the contracts and non-disclosures provide adequate protection for the worst possible failure (such as sensitive data leak). This is your insurance plan, so make sure you cover your bases and have contractual stipulations to protect your cloud relationship.
(3) Stage an unannounced vulnerability test on your cloud provider. Similar to when TSA is testing airport security with their security tiger team, you can execute a mock infiltration test scenario without the cloud provider security team knowing its coming. This will help you establish the confidence and TRUST that your data and systems have the highest level of protection (unless, they fail the test…)
(4) Walk before you run. Try before you buy. Date before your marry. Don’t put the most mission critical systems or applications in the cloud until you have confidence, cultural acceptance, and level of comfort through a cloud pilot. Build the TRUST needed through incremental successes and then go for the big enchilada when you’ve reached an appropriate milestone-- i.e cloud tested, verified, and trusted.
(5) Ask for weekly or monthly performance reports that show how effective and secure the cloud provider is performing. Make them earn your TRUST through metrics , quantitative analysis, and statistics.
(6) Tour the facilities where your cloud provider will host your solution. Make sure they show you exactly where your space will be located. You need to see your hosting space in person to TRUST that will be adequate.
(7) Ask for reference qualifications. See if others TRUST the provider as well. Ask the references how they overcame their trust concerns (peer advice).
(8) Ensure there are Key Performance Indicators that are contractually tied to the performance. This includes incentives and disincentives on their Service Level Agreements. Make them perform to the level of TRUST they have committed to.
(9) Keep a contingency plan and contingency architecture in case things don’t work out in the cloud and you need to drop back to Earth. If the TRUST fails and the cloud fails, you need a back-up plan so you are not left without the infrastructure to deliver your business capabilities. Cloud is a new, so a contingency is very important.
(10) Consult with diverse set of stakeholders in your organization to get their "cloud advice". Talk with the SOA, EA, IT Architects, developers, business users to get their opinions and recommendations. Make sure a broad group is surveyed to ensure cloud decisions are not made in a vac cum.
Subscribe to:
Posts (Atom)