Sunday, December 15, 2013

Application Security: An Afterthought for Most Organizations


My comment on this article from Infosecurity - The PonemonInstitute: Most Organziations are Woefully Behind in Application Security  was too long for LinkedIn where I found the original link so I stuck it out here.  A relevant and I think fairly accurate assessment when it comes to corporate IT application developers and security practices.  A generalization but a lot application developers are not adequately educated when it comes to application security practices.  Security is seen as a checkpoint item somewhere in the project lifecycle (if at all) versus integrated into the SDLC.  Another force at work is the relationship between the application developer and the security team.  It's not always a healthy one where application developers perceive correctly or not the security team's mission of just saying no.   

The other big elephant in the room is that the current security practices installed in most of the corporate world is the perimeter based defense approach to security, i.e. firewalls, proxies, dmzs etc.  This gives the application developer a false sense of security for their internally hosted applications and as result internal breaches account for some of the more devastating security breaches.  It's possible that the emerging thoughts around zero trust networks will help address this but it's certainly in the early stages.

From my viewpoint in the enterprise architecture world I think seeing security as a strategic enabler versus a defense or checkpoint can give an organization the ability to innovate at a far faster pace than those that do not.  Those that perceive security as a necessary evil or a drag on their efforts will struggle to keep up.  The great challenge of course is elevating security to that strategic enabler role and getting application developers to understand the importance.  Again an excellent article and a must read for CIOs and Enterprise Architects.

Sunday, November 03, 2013

Revisiting "The Cloud" and rise of the "uber developer"

The past year has seen some rapid advances in cloud computing adoption and advances in offerings.  The competition has heated up, Amazon is still the clear leader but Microsoft Azure and Google are starting to make some real noise and have the pocketbooks to do it.  Pretty much everyone else is in serious catch up mode and will have some major mind share as well financial obstacles to overcome, not impossible but definitely an uphill climb.

Most of you at this point, except the vendors in catch-up mode,  are probably nodding your heads thinking yes we know this tell us something we don't know.  What you may not know or see clearly yet is that the cloud model is giving rise to the concept of the "uber developer".  The rest of this post will explore the "uber developer" concept and why it may be the catalyst to your business and technology innovation.

Forrester released some research back in June looking at the state of public cloud platforms.  Here is a link to the article .  One key take away from the Forrester article was the classification of the types of developers present in a typical business IT shop.  Before we jump into that it is important to understand what a business IT shop is from my perspective.  A business IT shop is one found in the typical corporation where technology is not the primary business of the corporation ie not Google, Amazon, Netflix but rather corporations like Sears, Bank of America, American Express etc. 

To paraphrase Forrester's definitions there are existentially three types of developers in corporate IT shops: "coder", "rapid developers", "DevOps pros".   Coders are willing to write complex programs but don't want the burden of having to deal with the underlying infrastructure.  Rapid developers like all the complexity abstracted away and normally using the declarative GUI's, drag and drop coding if you will.  DevOps pros want to write the complex programs but also want complete control of the infrastructure as well.  They want all the knobs available to them, very little abstraction.  This DevOps pro is what I would classify as the "uber developer".

It is highly likely and preferable that you have all three types of developers within your organization. Heavily loading up on one type can create an imbalance in your organization's capability to both sustain and to innovate.  The rest of this post however will focus on the uber developer, innovation and the cloud. 

The uber developer is not a new concept and have existed since the beginning of the IT.  Uber developers are the developers constantly learning new stuff and wanting to learn and in a lot of cases control the entire stack of their applications including infrastructure.  It's important to distinguish uber developers from hackers or cowboy coders, uber developers are usually thoughtful and pragmatic about their solutions.  Uber developers know a lot about networks, hardware, operating systems, databases etc.  They have an absolute passion about understanding the entire application stack.

The majority of the traditional business IT shops don't have a lot of these types of developers for two primary reasons.  First, uber developers are attracted to start-ups and technology companies because the willingness to embrace new technology or solutions is high.  These types of developers are pragmatic risk takers, they are not afraid to press the button.  Second, business IT groups are heavily laden with compliance issues, legacy software, technology debt and extreme bureaucracy.   Uber developers and traditional IT business shops go together about as well as matter and anti-matter.

So what has changed? Why are we seeing the rise of this type of developer starting to exist for more than a brief moment in the traditional IT shop and what does this mean to your organization?  The answer is simple, it's the public cloud combined with open source software.  All the power and technology of modern IT is now available via a control panel and a credit card to anyone who has the desire and capability to use it.  It is the world's largest sandbox in the eyes of the uber developer and it's a match made in heaven.  And if you don't have any of these developers the tread marks on your forehead are you competition.  Innovation will be driven at the most successful companies by pairing these uber developers with capable business architects.

How do you know if you have any uber developers?  It's pretty simple since these developers have already figured out the power of the cloud.  Poll your development group and simply ask, how many of you have a private cloud account(s) with AWS, Google, Azure or other cloud provider?  If the answer is zero you are in trouble.  If the answer is we really don't know what the cloud is well RIP.  Simply having a private account is not the only indicator but it's a good starting point to getting to know what you have.

The modern IT landscape is changing at a velocity unprecedented in the modern era.  This rate of change is not only driving IT to figure itself out, it is also driving the velocity of business change.  Business leaders and architects now have information available to them and the ability to disseminate it at the speed of light.  The uber developer will be the link that drives innovated solutions that meets the demands of business.  The future IT shop will look much different in just a few years with uber developers being the dominate innovation engine and mainstay within the IT shop. 

Sunday, February 19, 2012

Cloud FUD on Multitenancy

A recent blog post from Eric Lai titled Multitenancy and Cloud Platforms: Four Big Problems (Note: the post also appeared on Wired.com as well) had some big problems itself.  I wouldn't normally write a blog post on something like this as the entry was an obvious sales pitch for a new Sybase product however...... the article just got a little to much air time.  To summarize the article: PaaS vendors have issues with security, globalization/localization, developer productivity and inflexibility.  I'll walk through the "Four Big Problems" as presented by Eric and give you the perspective of a corporate IT architect versus a vendor.

Big Problem #1 - "It's inflexible"

The example used here mixed up PaaS and SaaS.  Google's email system was the target of the inflexible which doesn't allow the user to specify where their data will be stored potentially violating industry or governmental regulations.  It also goes on to mention Coke not wanting to store their secret formula within the same instance of a something as Pepsi.  PaaS is then brought up as not being flexible enough to handle these situations.

Google email's system would be an example of a SaaS and not PaaS as implied.  Localization of data has absolutely nothing to do with multitenancy.  Google's email system is a bad example to use when discussing PaaS because it's not one however for the sake of argument let's just say that localization of data would be an issue in a dedicated hosting scenario as well.   Multitenancy does not preclude you from directing where your data will be stored, the geo-locations of your cloud provider may or if you went the dedicated hosting route, same issue.

By the way Pepsi and Coke both use Azure which is a PaaS offering from Microsoft.  I doubt they store their secret formulas there or anywhere else that has network access.  Not a multitenancy issue either, just common sense.  To sum this up most PaaS providers have regional datacenters across the  globe and have extremely flexible ways of directing where your application and data spin up.


Big Problem #2 - "It's less secure"

The big example used here is a common one which is if a hacker manages to get into a multitenant database then all the data is compromised.   I would encourage anyone contemplating PaaS solutions to do their due diligence when selecting a provider.  Ultimately you and your security folks have to be comfortable with the safeguards put in place by the vendor.  But there is a lot of FUD here so let's address some it.

If you have discussions with the PaaS vendors and compare their security protocols and procedures you will mostly likely find that they are light-years ahead of what you are doing or would be capable of doing.  It's really a fairly simple concept, a vendor such as Amazon or Microsoft or Google can afford and do hire the very best security personnel available.  It does not mean they are incapable of making mistakes but the odds are with them versus you. Do your homework on this one but you will be impressed and more secure.

The second thing to keep in mind is that there is more to multitenancy than the article would leave you to believe.  There is more separating your data from Pepsi in a multitenant database that a username and password.  There are multiple layers of protection to isolate you from the other users in those multitenant environments.   Your data is not more or less secure because of multitenancy.  PaaS does a lot to help you out and abstract away some of the complexity but it's still up to you to make sure your data is secure and that would be the same for a single isolated hosted instance.

Big Problem #3 - "It's less powerful"

This one was a little strange.  It really didn't explain why a PaaS would be less powerful than a standalone instance of an application or database other than say Database.com doesn't use standard SQL and Microsoft might not have a datacenter in your region.   I think common sense would suggest otherwise.  How elastic can your standalone application or database be?  How easy is it to deploy your standalone application or database to multiple datacenters/regions around the world taking into account globalization and localization issues without specific version of your application to handle each?  Somehow a standalone instance of something wouldn't have scalability issues? Or wouldn't have localization issues?



Big Problem #4 - "It may be more costly"

ROI is always a tricky one and the point made by the author here is that you may have to rewrite you application to run in a PaaS space.  I happen to agree with the author on this one.  You have to weigh the benefits versus the cost of any application you do.  If the cost benefit does work out ten you have to question the project.  This however has absolutely nothing to do with multitenancy.

To summarize I think the author missed a chance to promote his product with more rational set of arguments.  PaaS has some issues but multitenancy isn't really one of them.  When comparing a potential cloud solution for an application you are really looking at IaaS, PaaS and SaaS.  They all have their benefits and drawbacks.  The big one I think the author missed his chance on was the potential vendor lock-in with PaaS which could be a very real issue.    IaaS, PaaS and SaaS all have degrees of lock-in but that's the subject of another post.

Tuesday, June 28, 2011

The Rise of The Cloud

There is an interesting read over at eWeek on what McDonald's is doing in the cloud.  Okay so I know most of you don't think of flexibility and IBM toolsets in the same sentence but that's what the article is about(Just joking IBM, you have very nice tools).  I was more interested in this quote in the article from an IT Manager at McDonald's:

“McDonald’s is a hamburger company; we don’t want to be in the IT business,” Farnum said. “We want to focus on what we do best.
What seems to be a simple and obvious statement is not at all what it appears.   How many IT managers can walk down the line and directly tie their employees day to day activities with what the company is trying to achieve?  How many employees are constantly on thought, what am I doing today to help make better X and sale more X?

By now some of the more astute of you are trying to figure out the blog title and how it is related to this post.  The rise of the cloud has surfaced an ugly truth within some IT departments.  There are a fair number of IT employees if not whole departments engaged in simple self preservation in response to the rise of the cloud.  The irony in this is that they should be doing just the opposite.  You know how Anakin went to the dark side in order to save Padme but that very act is what caused her death, it's just like that.

The cloud if used correctly can provide the IT department with the tools to be the responsive agile group it's business partner so desperately wants it to be.  There are a few basic things one should know before embarking on this journey.  I'm not going to cover the hard stuff, you'll have to figure those out for yourself just like I did, have fun.

-First thing, it's a journey you have to take.  If you ignore the cloud you will be consumed by lava and forced into a life on the dark side.  Seriously don't let your business users get out ahead of you, they will create a mess and leave you behind in the process.

-Don't ignore and take for granted your data privacy policies.  The big cloud guys are likely to be more secure than you but don't take their word for it.  Understand the issues, know what you can and cannot let into the cloud.

-Don't just try and port your crappy architecture into the cloud.  Ha Ha I know you don't have crappy architecture but seriously there are ways of doing stuff in the cloud that will let you take advantage of all that elasticity.  Moving your applications/infrastructure to the cloud doesn't relieve you of understanding the architecture, be sure to know what is going on behind the curtain.

-Don't be afraid, remember fear is the path to the dark side.  I took a cloud development class a while back for a certain vendor and was amazed at how many developers would not sign up for the free account. Microsoft's Azure, Amazon, Salesforce (if you want to try some SaaS) all have developer programs that will cost you nothing to next to nothing.  Jump in and try it out.

Get out in front of this and make your IT department the hero of the business and not the slow moving self-preserving Luddite.

Tuesday, March 22, 2011

The Cloud Architect

David Linthicum had a very good post over on InfoWorld about cloud architects versus enterprise architects. I'm summarizing David but in a nutshell the article is about the need for SOA skills to be a cloud architect. While I totally agree with the need for SOA skills in the cloud space, I think cloud architecture may encompass more than one type of architect.

The uber architect generally just doesn't exist in corporate IT. There generally is a conglomerate of architects that make up the "virtual" uber architect for a corporate IT shop. The cloud really expands on this need because of the different areas of expertise needed in more detail i.e. security, infrastructure and SOA (for sure). Let's also throw in parallel computing for kicks and grins so that we can take advantage of the potential elastic nature of compute nodes. A SOA Architect would have the best chance of having most of the skills in various levels of depth but I think finding all of these in one architect is going to be difficult. SOA itself requires a broad range of skills difficult to find in one person.

Remember the ICC? Integration Competency Center. I'm seeing a future for the CCC or C3 (Cloud Competency Center). In all seriousness it's going to take several architects to screw in the cloud powered light bulb.

Thursday, December 30, 2010

End-Users Are Getting Smarter

We know that the end-user is getting smarter. The exposure to computing and applications at a very early age is at an all time high. That knowledge brings different expectations.


Image by Free-StockPhotos.com

The question becomes how does the modern IT shop deal with this? The answer is drum roll please ...... Cloud Computing. Ha just kidding with you. The answer is actually there isn't any one answer.

The issues facing the modern IT shop due to the increasing intelligence of the average end-user are multifaceted. There are data issues, security issues, interaction issues, privacy issues, usage issues, maintainability issues and the list goes on. Certainly some of the traditional ways of dealing with these issues will still apply but I think new ways of thinking are needed for the "IT Shop" to stay relevant.

First it's important to understand that we are dealing with evolution and not revolution. The evolution we are discussing is happening but not overnight. This is not a dinosaur extinction event yet. Here are a few thoughts on not only survival but on thriving as an IT community.

-IT quit using the term "the business". I cringe every time I hear someone in "IT" say "the business" wants this or "the business" needs that. You are the business, start acting like it.

-End-users aren't dumb, stop treating them that way. Talk to them, listen when they speak and realize you are all in the same boat wanting the same thing.

-Waterfall is dead, it was hit by an asteroid. Stop trying to use it and move on for Pete's sake.

-Cloud computing is for real but it's not for everything. Learn how to leverage it for the right things and make sure your end-users aren't leveraging for the wrong things.

-In a complete contradiction to the above suggestion, you will almost certainly lose control of your data at some point. Figure out how to deal with that eventuality.

-Social networking is not only not going to go away it's going to get a lot bigger. The key point here is that it really doesn't matter whether you get it or not, the end-users do and they are going to want more of it. Learn to deal with it least you become a target of that asteroid.

-Security has to move out of the I hate to have to deal with security to being at the forefront of all things. End-users even though smart have to be educated even more on data security.

-IT Developers, you going to hate this but you are more valuable the less code you write. Learn about SOA, embrace reuse. Learn and use tools that help you achieve this. There are jobs out there for code jockeys but the IT shop generally isn't it anymore.

The modern end-user is smart and very comfortable with technology. To keep up the "IT Shop" must embrace this.

Tuesday, December 21, 2010

Cloud Stuff - Did you get the source code?

David Linthicum's recent post on cloud providers dropping either user sites or applications reminded me of the old vendor source code negotiations. The basic premise is before purchasing a really expensive piece of software you got the vendor to agree to give you the source code in the event they go out of business. This was suppose to alleviate some of the fears of the big check that was about to be written. The vendor goes out of business you still have working software plus the source code(No I don't know what you would do with it).

The cloud has changed the game. Not only do you not get the source code, the vendor can turn you off in an instance leaving you with no working software at all. As David points out, getting vendors to sign SLAs that help you more than them is pretty tough. This obviously is cause for concern with a lot of IT organizations consider moving applications, services and infrastructure to the cloud. Of course there are tons of ways to mediate all of this and still take advantage of what the cloud has to offer. Things such as SOA, Governance, EA and even the old EAI(Practice not the platform) standby all still apply when designing for the cloud(location independence takes on a more significant role).

The take home message is get out in front and don't throw good architecture practices out the window because there is something shiny and new out there. The cloud demands your architecture be more sound than ever.

Monday, November 29, 2010

The Future of IT

ZapThink has an interesting article out on the looming Enterprise App Vendor Crisis. The article is really a continuation of several thoughts that ZapThink has on the state of the IT organization and its role in the modern business world. The overall underlying theme is that IT organizations are undergoing a major change that will result in a substantially different appearance in the next few years.

The article offer a lot of insightful and rational points in its trek back to 2004 and back to present day. For those of us who work in "The IT Shop" I think we can see the reality of the predictions in small doses. It's probably a reasonable assumption to make that most understand these type of predictions are generally made with a broad stroke. There are literally thousands of IT shops and businesses so sweeping generalizations must be applied when making predictions.

One issue I think most analysts have is that they generally are interacting with the facade layer of a given organization. The guts of an organization and how it really operates is generally hidden from external view. Of course this is a generalization as well on my part but I think a fairly valid one based upon my experiences. This really isn't the fault of the analyst.

There are a significant number of analyst engagements that are initiated by senior level staff within either the IT group or a line of business within an organization. The reasons can vary for these engagements but a common theme is usually checking your direction/thoughts on strategy, projects etc with that of an expert(s) external to your organization. It's really not a bad idea when you think about it however the problem develops in your presentation of yourself.

This leads us back to our external analysts. Analyst engage and work with an organization based on a highly filtered view of that organization. Organizations just like the people that work in them tend to present themselves in a very favorable light. ZapThink's predictions resonate with me and have logical progression. The issue I think is that the predictions are based upon a state that in most cases is actually not known.

IT still has a very bright future in the modern business world. It will change over time as ZapThink suggest but that rate of change will be much slower and will probably fork off the predicted path many times just as evolution tends to do.

Wednesday, August 18, 2010

Random Thoughts on Enterprise Architecture

Enterprise Architecture (EA) is getting a lot of press lately some of which is good and some not so good. There seems to be a lot of disagreement on what EA is and isn't. There is also disagreement on the value of EA. I'm not attempting to address either of those items just jotting down some observations as I monitor these conversations.

-How come it take so long for us IT folks to get a definition of something locked down? SOA, Cloud Computing, EA all are still debated on simple definition. This just serves to confuse others and generally hurts the overall progress.

-EA is evolving into distinct camps: Traditional EA which is IT based and heavy on the frameworks, business based which wants to evolve EA into the entire enterprise with IT just another component of that and a hybrid camp which is trying to bridge the gap.

-All of the EA discussions appear to still be IT based. I haven't seen a lot of business leaders jumping into the discussions. Some IT folks want to evolve EA beyond IT but have the business folks bought into that? Are the business schools focused in or have any discussions on EA at all?

-To much focus on the EA Frameworks can hurt the overall effort of EA. EA's become paper pushers and not architects.

Those are some random thoughts/observations I had while monitoring these ongoing EA conversations. The scope of EA seems to be the most hotly debated. EA is obviously focused on the business but at what level? I think that one is going to be tough to answer without business leaders joining in the conversation.

Thursday, April 29, 2010

Software Quality

A few thoughts on software quality which seems to be a topic coming up more frequently these days. The first I'm throwing out there is software quality can be a fairly complex topic so a simple blog post is not going to attempt to do it justice. The next thought is software quality means different things to different businesses or organizations. The expectations of the space shuttle crew of their software is different from the folks who need an internal web page to track office supplies. Although it may seem like the folks who need the web page are in fact launching a space shuttle, that is not the case and the same rigor cannot and should not be applied.

Two areas in particular that I'm ranting a bit about are SOA and Agile(as in the development methodology). I read this post over at CIO.com on the issues that SOA and Agile bring out when it comes to software quality. I'm going to answer the question it's posing up front - no SOA and Agile do not lead to crappy business agility. I think most would agree that have had successful practices established around SOA or used the Agile development methodology correctly that the end result are more agile applications.

Organizations that skimmed the service of SOA or Agile could have implemented complete disasters for software. Does that make SOA or Agile the culprit? I think not and in fact I think those same organizations would struggle within any architecture or methodology. SOA and Agile don't shed the traditional principals of good software development practices, they simply enhance them to insure business needs are met in a timely manner. Like any architecture or development methodology if implemented incorrectly SOA or Agile can lead to bad results. If you have any thoughts on why SOA or Agile in particular lead to poor quality software, I'm all ears.