Saturday, January 31, 2009
Thoughts on Facebook
Friday, January 30, 2009
Convincing an organization that they aren't doing SCRUM...
One would have been much better off espousing the individual techniques that were used than claiming that the Scrum methodology was applied. Using only certain Scrum techniques and adopting only some of the Scrum characteristics may not preclude you from claiming you are agile. However, I would use this analogy to show why you cannot profess to be using true Scrum: Can you say you've made a batch of chocolate chip cookies if you leave out the chocolate chips?
Now, Let's focus on one Agile principle which is the notion of self-organizing teams. Now ask yourself, do you think this is even possible in the world of tainted governance? Consider that ducks when flying south for the Winter are self-organizing (Don't draw a mental picture of project management and all the quacking that occurs) or penguins. Did you know that male penguins stay in the middle of the antartic continent for months with an egg on their feet keeping each other warm? Self-organization requires leadership and sacrifice where very large enterprises are more centered around more selfish outlooks where it is rare that you are rewarded for sacrificing for the greater good.
Anyway, self-organizing works in that talent is not constrained to follow a pre-defined process. This is counter to the notion of governance and review cycles. I am an Agilist but also an Enterprise Architect who focuses on security, so the ability to live in an iterative world constrained by command and control is something I have come to grips with. Instead of sugar-coating my world, part of self-organizing is to acknowledge one's constraints and work around them accordingly.
Self-organization requires the ability to discover common passion kinda like pickup basketball games in the neighborhood. Two kids find they have the same passion and run with it. For me to be successful in the security space, I participate in OWASP which is the poster child for self-organizing teams. When my IT peers attend OWASP meetings, they tend to show their passion and we can all work towards a common goal.
Sadly, there is no passion in IT around other important domains. I haven't seen passion around approaches to BPM, business rules, ECM or even SOA. Sure, we can twist our false sense of worth in our day jobs with our grimace smiles into passion, but the results are transparent and we as a profession are failing. Self-organizing teams is what can best align business with IT for strategic competitive advantage...
I can't believe that enterprises pay analysts money...
- “Succeeding with enterprise architecture is challenging. But if done properly, it provides a balance of quick, easy wins and amazing long-term business value.”
Now, if you really want insight, remember to always have strong business buy-in and a sound ROI. Oops, you have to also remember to incorporate the phrase best practices into your daily vocabulary and you will be successful...
Thursday, January 29, 2009
Random Thoughts for 2009-01-29
Anyway, I have a few of them planned and you will be able to listen to me on your MP3 player shortly...
Condolences: Master Helio Gracie...
Wednesday, January 28, 2009
Worst Practices in writing specifications...
Bet your business analyst can't answer the above question. Is it because we are following the worst practices of CMMI and focusing on creation of comprehensive documentation while ignoring what is most important?
A flat-out specification list is not economical. This is because in reality the features actually requested are not all-or-nothing. Some are necessary and some are "nice to have". But because a specification usually makes no distinction, one will pay for features even if they are expensive to implement (and also skip features that may otherwise be cheap).
A more economical approach would use give-and-take, using a formula similar to:
rank = need / cost
This would reduce the probability of implementing expensive features that are not really needed or have cheaper alternatives. However, this also complicates the negotiation process. An all-or-nothing fixed-bid list is much easier to administer and compare across vendors/contractors and therefore the folks over in procurement help sabotage the business value proposition.
I have always found it curious why Indian outsourcing firms such as TCS, Wipro, Infosys, Satyam and Cognizant have never asked enterprises to change their model in this regard? It would only help them to deliver higher quality in that they do need to appear as buffoons who are clueless and/or overwhelmed when it comes to understanding client requirements and instead could learn and implement incrementally.
What am I missing?
Tuesday, January 27, 2009
Links for 2009-01-27
An interesting perspective on the length of resumes from folks in India and the burden of arrival. Maybe one answer is for us American's to figure out ways to for us to help Indian's adjust to our culture. Of course, it requires folks from India to also ask...
Bex Huff states: I feel that a college degree means you can learn, experience means you've made the typical rookie mistakes, and certifications/conference attendance means you're dedicated to continuing your education which is accurate. When was the last time you ever met anyone from India in IT that didn't have a degree? So, we need something else to discriminate and certifications becomes the next easiest target. I wonder how Bex, Joel Spolsky or others would otherwise suggest that corporate recruiters who receive tens of thousands of resumes filter them down to something more managable.
If BPM vendors don't have a clue as to what static analysis means, does this mean that BPM platforms are an easy target for potential hackers? I wonder if Lombardi software, pegasystems and others suffer from the same lack of knowledge?
Roland Hesz amplifies a most important topic...
Monday, January 26, 2009
2009 Resolutions for Enterprise Architects
1. Start building an alumni network. In case you haven't been paying attention, Indian outsourcing firms are now the biggest risk. We caught Satyam lying and the employees are bailing leaving your outsourced portfolio exposed. You are aware of how long knowledge transfer takes and therefore the smart option would be keeping in context with all those employees the enterprise was stupid enough to let go off to save you later.
2. Stop being the exception that enforces the rules. Enterprise architecture is not a police force or bearer of standards, CMMi, common message formats, etc. Enterprise architecture is all about enabling the strategic intent of the business and therefore should focus on people over process and innovation over foolish consistency.
3. Start scouting for key talent. How innovative can you be in an outsourced model when folks in India stop being developers in order to become managers in five or so years? Talent is best groomed in a local context.
4. Start preparing for the unexpected. Satyam, Bear Stearns, etc are all examples of companies not preparing for what happens when a key business partner goes out of business? What would you do if you discovered that Documentum DFS was the intellectual property of Insecure Architecture Anonymous who asserted a claim against your enterprise SCO style? Indemnification and agreements are meaningless if the other party no longer exists.
5. Start using social systems yourself, visibly. If you aren't on LinkedIn and networking with your industry peers, then you are an idiot. Think about the benefits of Wachovia employees who networked with their new bosses in advance vs those who didn't.
6. Start taking security seriously. From one seat, folks will think that regulations are a waste of precious capital while another side will think that we didn't have enough. Which side do you think will win the argument? If you haven't been paying attention to OWASP then you should, as it is at the cornerstone of many regulations such as the next version of Basel, PCI 2.0 and the Unified Compliance Framework.
7. Stop ignoring people and focusing on process. Your savage focus on process will collapse. You need to focus on immediate needs such as financial survival and spending money on things with nebulous payoffs such as ITIL and CMMi are questionable in today's climate.
8. Start offering your vendors a free lunch. Why aren't you demanding more of them? Instead of customizing, why don't you figure out how to generalize your requirements such that they can be leveraged by other organizations and demand that they be included in the next version at contract time. Influence is good. Having a longer-term outlook on the features you need and demanding them at contract time is better.
9. Stop fearing the future; start driving it. Let's face it, if you are looking at Gartner magic quadrants, then you are practicing history and not architecture. At some level, the historical revenue figures of enterprise vendors is important, but driving their roadmaps is more important. If you aren't engaging the vendors and demanding new features and thinking about them as an extension then you aren't doing your job.
10. Discover newer technologies to get experience of in 2009. New technologies may allow you to rationalize away multiple older technologies with one new one. The enterprise needs less products, less vendors and less people governing them and new technologies is the potential opportunity to make this better.
OWASP Hartford: February 2009
OWASP events are 100% free to attend. Help spread the word especially to folks who work for Cognizant, Wipro, IBM and Accenture...
Sunday, January 25, 2009
What does a "would & could attend" IT conference look like?
- Of the elements I've included in the blue circle above, which are most important to you?
I care most about compelling topics more than the credentials of the presenter. Way too many conferences focus on those who have excelled at Toastmasters but otherwise don't convey much useful information (Gartner conferences come to mind). I rate peer interaction as a second consideration in that I tend to like to hear what others are up to directly from them vs hearing some analyst tell the story on their behalf.
- For instance, does a "credible speaker" have to be high-profile?
I don't care about the CIO title or other figureheads where I might care about those whose are lower on the foodchain who actually get the job done. I guess I am not interested in best practice Gartner style handwaving and posturing. I want to learn something.
- Would you be interested in a highly participatory, un-conference type format?
- How about topics? What's of interest? Would you rather go broad or deep?
- Then, on the red constraints circle, what are you willing to put up with for a low cost, high value event? A 30-45 minute sponsor talk (pitch)? Follow-on conversation with said sponsor?
- Or, perhaps a no-frills approach? Bring your own lunch? Hosting a small gathering at your organization? Other ideas?
Saturday, January 24, 2009
Prescriptive compliance weakens enterprise security...
Ever ran across an Enterprise Architect who thinks what they do is somehow related to the building trades? Sadly, the conversation has shifted away from more important topics such as the OWASP Top Ten and learning how to build applications securely upfront to after the fact remediation.
The notion of building codes isn't meant to be the goal but is meant to be the minimum that a plumber, carpenter or electrician should meet. In the building trades, they do aspire to do better than code, but the same thing can't always be said of architects.
The funny thing is that our business customers truly want us to deliver secure software and they would like for us to be proactive yet we speak to them about spending millions of dollars on after the fact compliance. They want to pay for security that enables the strategic intent of the business and not stuff that is already amortized. Why are we always playing with dead snakes?
So, in my mind wouldn't it serve both demographics if we talked about technologies such as federated identity? Instead of having silly policies on password complexity, why shouldn't we all be having a conversation on eliminating passwords? Imagine if all enterprise applications could leverage Cardspace, we wouldn't worry about rainbow tables or whether I changed my password in the last sixty days. In other words, federated identity enable both the strategic intent in a going forward basis but also address compliance.
More importantly, there are some of us who want to use security as a strategic weapon yet are handicapped by foolish consistency. Using prescriptive regulatory compliance to “get your way” removes your ability to be a better architect and therefore have proper influence in building secure software.
If enterprise architects can't help make good decisions and therefore, in the eyes of management do not deserve the right to make the decisions that need to happen. Enterprise security needs to be more than just the guys who manages our PCI stuff. As Gunnar Peterson might say, you can't have security if someone else is telling you how to spend your budget...
Friday, January 23, 2009
Insecure Federated Identity Deployments
In today's posting, I wanted to analyze the response provided by Pat Patterson of Sun as well as ask some additional questions to see if anyone has the answers.
- The most obvious mitigation is the use of SAML 2.0 persistent identifiers. A persistent identifier is an opaque string (in practice, a long random sequence of characters, such as ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M that is shared by exactly one identity provider and one service provider to identify a given user.
- Federation products tend to be separate and distinct from web access management products.
- All good points from James, I have to say, illustrating the fact that, even if your wire protocol is secure, implementation issues can easily lead to vulnerabilities.
- There are other ways of implementing this that spring to mind; segregating local and federated users into different domains for example, or testing some attribute in the user profile.
Now for some additional questions:
1. If a federated identity product is deployed as a separate tier from an application and the IDP when sending an assertion needs to not only send values that may be stored in a directory (e.g. OpenDS, OpenLDAP, etc) but also include values that may be calculated by the application at runtime, how would this work? What APIs would be used and more importantly what APIs should exist but are missing?
2. SAML 2.0 identifiers is a great concept and Pat shows how OpenSSO can leverage them. I am curious though when they are stored in a directory service such as OpenDS, should they have a standard IETF OID for holding this attribute/objectClass?
3. I haven't looked in detail, but the SAML 2.0 identifier outlined feels the same as the PPID leveraged in Cardspace. If they are different, then did Microsoft violate some principle? If they are the same, then shouldn't there be a standard as to how this is represented as MS will generate it differently than Sun? What other "best practices" exist around generating this value?
4. Did Gerry Gebel of the Burton Group test out these scenarios at the Catalyst conference?
5. Recently, I had the opportunity to hang out with some folks from Voltage who discussed the concept of identity based encryption (IBE). Should federations support IBE in addition to traditional PKI approaches?
6. Does Sun have any plans on making the J2EE Petstore OpenID and federation-enabled?
Random Thoughts for 2009-01-23
Thursday, January 22, 2009
How Indian Outsourcing Firms should exploit enterprise clients...
Can we acknowledge that enterprises can make their processes heavier and more documented but otherwise don't have the ability to truly add maturity to their processes? So, maybe they should stop attempting to align and instead start attempting to exploit.
Walk the corridors of a large enterprise and gather up all the process weenies you can find. Encourage IT executives to put them in charge of all outsourcing efforts and congratulate them for achieving paper-based milestones while ignoring the fact that you can't put comprehensive documentation into production. Convince them that working software isn't important as their customers don't come to their web sites to order products but to understand where they are in terms of CMMI maturity models.
Indian outsourcing firms should fix bid everything! No matter what the project requirements include, fix bid it for $1. Take advantage of foolish consistency in that they will advocate to everyone the stellar deal they negotiated and put into their statuses that they are ahead of budget. Set them up to look stupid or should I say dependent on you. The tactics of drug dealers is to give their product away cheaply upfront until they are addicted. Align your approach to this thinking until they can no longer say no.
A hooked client after having promised delivery of something cheap will be owned. In fact, they will compromise their own budget and you don't have to look like the bad guy once all those change orders start rolling in. Let's face it, no one on the planet can define all the requirements for a system upfront yet there are lots of process weenies that will attempt to try!
Links for 2009-01-22
The trend of securing access to ECM platforms such as Microsoft Sharepoint via XACML is growing by leaps and bounds. I am curious when Microsoft will wake up and realize that they should support this natively versus encouraging others to bolt-on security after the fact?
Everyone has a different expectation of what a reference architecture should contain. My definition would include some mention of the security model used since claims data can contain anything and everything from credit cards to social security numbers to healthcare information and therefore is a great source of risk. The ecosystem of claims also includes lots of third parties from doctors, to lawyers to autobody shops and so on. How does the world of identity look through this lens?
Mark Diodati of the Burton Group provides insight as to how SPML can enable better provisioning to enterprise applications. The IdM crowd hasn't talked much about rationale for separating the provisioning service interface from the user interface from workflow which would be more inlne with SOA and other architectural styles. This of course, may call out the fact that most provisioning products are monolithic in their architecture.
Mike Tracy of Matasano challenges an article posted by Gary McGraw on the value of Top N lists which I agree. While I believe that distillation is a mental disorder, it happens to be the status quo for many enterprise architecture teams and allows them to at least get an understanding of what they need to focus on. Of course, most shops never make it past Top N lists but the suboptimal behavior of humans doesn't make the concept flawed.
Wednesday, January 21, 2009
Comparing Accenture to IBM
The primary difference that I have noticed between these two firms is in culture. From my seat, Accenture lets the "best idea" win where IBM seems to be based more on where one falls in the hierarchy. Accenture gives young persons a lot of responsibility and expects them to sink or swim while providing excellent training and resources where as IBM seems to also believe in the sink or swim without always backing it with the right support model and instead relies on consultants to build their own networks for support and learning is more under fire or via online training but almost never through conferences or more effective methods that usually require physical presence.
I also had the opportunity to see the annual review cycle for both firms in that consultants from both had asked me to provide input to their managers. In one firm, it seemed as if they were handed their personal development goals while another allowed them to create their own. It is difficult to determine which model is better as there are times in my own career where I have preferred one over another.
For example, many shops force your boss to participate in HR exercises where it is more of a ritual than anything meaningful. In this situation, I would rather just have it handed to me so as to not waste precious time of me actually thinking about how to improve without of course getting a budget for conferences, training or even purchasing books. For companies I have worked for that did value education and backed it with real tangible dollars, the model of creating your own development plan feels more appropriate.
Another experience that I have had was in encouraging folks from both firms to participate in my local OWASP chapter. The Accenture partner embraced the idea and immediately forwarded the calendar invite to everyone he knew where the IBM partner made less effort. I get the general feeling that to be a partner in Accenture comes with more responsibility, more autonomy and more desire in the way of making the client happy than in IBM.
On the other side, I think the IBM partner model feels more structured which is beneficial to clients who want their interactions to feel more scripted. There are times when you desire waterfall and IBM feels better in delivering against this model where everything is known upfront while Accenture feels more comfortable in an agile environment that is a lot less locked down.
A former co-author of mines, Scott Ambler is currently employed by IBM and is working very hard to encourage the engine to become lighterweight. I wonder what internal struggles he would love to talk about. I wonder if IBM will allow him to be truly successful?
Speaking of Scott, I remember several years ago an interesting debate he had in attempting to convince an Accenture consultant who was based in India that the only thing that proves working software is working software. The concept that comprehensive documentation proves working software is still a concept that is lost on both firms.
Finally, I would say that IBM cares about its employees a little bit more in that they have figured out more in the way of helping us thick headed client types eschew face time and instead work from home. I get the sense that work/life balance is more valued at IBM than it is at Accenture.
If you have any thoughts on Accenture vs IBM, please trackback or leave a comment...
Tuesday, January 20, 2009
Random Thoughts for 2009-01-20
Team OWASP 2009
Check out the OWASP lending team, and learn more about lending teams on Kiva in general, by clicking here.
I wonder what it would take to encourage George Bush and Barack Obama to join...
Enterprise Architecture: Is 2009 the year of anti-process?
The savage focus on process is destroying innovation within large enterprises. 2009 is the year where we need to focus on the human aspects of technology and solve for the impeding knowledge crisis. Let's be honest with ourselves and acknowledge that in the history of IT, no process has truly saved the business money. Sure, we can get creative and account for cost avoidance but if we look at IT holistically, it certainly isn't getting cheaper nor more efficient.
So, would you rather restrict smart people from doing smart things or dumb people from doing dumb things? This is not about intelligence quotients nor their ability to even pay attention but rather acknowledging that if folks are effective at their jobs, regardless of whether they are the CIO, an enterprise architect or even a process weenie like Robert McIlree, you really don't need a lot of rules.
So, when will Nick Malik and the Gartner crowd ever do a great service for their end customers and figure out a methodology that will help large enterprises understand when the processes they implement are counter-productive...
Monday, January 19, 2009
Random Thoughts for 2009-01-19
No more George Bush...| | View blog reactions
Sunday, January 18, 2009
Random Thoughts for 2009-01-18
Saturday, January 17, 2009
Business Rules and Complex Event Processing
The folks down the street at ESPN have scheduling challenges that are even more complex than airlines. Did you ever consider the fact that in order to display a commercial, you can't always plan exactly when it will air upfront? In sports such as football, the ability to predict commercial scheduling more than 10 seconds in advance is problematic.
Not only is the time considerations a challenge, but you also have to take into account the fact that you would never display a Coke advertisement back to back with a Pepsi advertisement. Sure, it would be easy to identify competitive situations as part of an algorithm, but it is more complex than that as well. Bet you never thought about the subliminal message of displaying a Budweiser commercial right after a commercial for Ford trucks. I could see class action lawsuits for those who would immediately be guilty of being an idiot by reading into the message vs just reading the message.
So, whether you are using Fair Isaac Blaze, iLog, Drools or some other business rules engine, how would it work in an overall scheduling architecture that includes complex event processing where the event is some opportunity to go to commercial break and the rule would need to determine the next commercial to show? I wonder if James Taylor, James Governor or any other brilliant person named James in the blogosphere has any thoughts on how they would approach this scenario?
Friday, January 16, 2009
Links for 2009-01-16
Jackson Shaw provides an insightful look into the inner thinking of Microsoft. Someone at MS must care? More curious is why folks at the Liberty Alliance aren't advocating for this?
While process is important, values are more important...
The identity crowd has been notoriously silent when it comes to best practices in mapping enterprise applications, roles and other considerations into claims. Hopefully, others will chime in and discuss this important topic.
Thursday, January 15, 2009
Enterprise Architecture and getting called to the carpet
Gaining buy-in is both good and bad. Sadly, this is the mantra of Gartner. Likewise, the best way to accomplish this goal is through the worst practices of focusing on process over competence.
Nowadays, the trend of getting called to the carpet occurs when folks attempt to do the right thing vs what is popular. What does it say about your enterprise if it is better to duckdown than to do the right thing?
Why does your boss need to publicly support you when the facts should stand on their own? Have we lost the ability to do fact based reasoning? Is enterprise architecture nothing but a glorified ponzi scheme that was embraced by Madoff or do we have a higher calling?
Wednesday, January 14, 2009
Agile has the potential of becoming an IT worst practice...
Another architect I know, recently commented that in 1999, if he presented a suboptimal (aka half-assed) architecture, he would have gotten it handed to him. In 2009, he can present suboptimal architectures with relative ease but if he violates the "process" he will get it handed to him. Is this true in your shop?
Seeing things through the lens of process encourages folks to focus on things such as CMMi and Scrum while ignoring practices such as extreme programming which has the potential of increasing quality.
My theory on it is that there's an increasing lack of architectural competency, which leads to the inability of an architectural governance group to form an educated opinion regarding the technical quality of any particular architecture.
When you factor in the political power that many architectural governance boards have, you end up with power brokering just to be in the group. All of that leads to a lack of technical knowledge. So, how does a non-technical group make evaluations of technical solutions? They rely on something they can understand and measure, like whether the solution follows the process.
It doesn't take long for the governance group, often driven by politics and power brokering, to start claiming success based their metrics for "process following". Reported success leads to more power, ad infinitum.
On the other hand, there's more than one way to skin this cat. You could argue that there's a "minimum" technical solution which meets the business case at hand, and some range of solutions from there up to the "optimal" technical solution. It would then be a matter of cost/benefit analysis in determining the best solution overall for the business. Of course, in this model, you would still need the technical expertise in order to identify whether the solution at hand is "minimum" or better; a process, by itself, will not suffice.
Tuesday, January 13, 2009
Random Thoughts for 2009-01-13
Monday, January 12, 2009
Did you know that many federated identity deployments are insecure?
I apologize in advance to Pat Patterson, Nishant Kaushik, Gerry Gebel, Johannes Ernst, Bob Blakely, Kim Cameron, Mike Jones, Ashish Jain, Patrick Harding and others for bringing up the issues I will discuss. Hopefully, they will appreciate the notion that from incite comes insight.
First, let's dig into OpenID. An OpenID XRI can look like anything, including a SQL injection attack. Shouldn't this mean that folks over in this community should noodle at least some type of regular expression of permissible identifiers vs leaving it as yet another weakness?
Second, many of the federation products when serving in the role of relying party can potentially create several new exposures. Many of the products will perform a lookup of the subject within a SAML assertion against an LDAP store. Imagine in a world of SaaS should salesforce.com choose to use one of the off the shelf products, would this be sufficient? Of course not as there is a gap in logic.
So, if salesforce.com is a SP and supports multiple customers of which Credit Suisse is one and the other is say Goldman Sachs. Salesforce.com would have a trust relationship with both of them but what would prevent a rogue Goldman Sachs employee from putting into their directory the subject (say email address) of a Credit Suisse employee and allowing it to be passed along? More importantly, the SP should do more than trust as we all believe in the security principle of trust but verify and therefore would need to have entitlements capability built into the proxy in order to defend against this type of attack.
Have you ever looked at how this would be discovered after the fact from a forensic perspective? Hopefully, they are logging all federation activities to a separate tier and leveraging products such as loglogic, splunk, logarithm, etc but are the log records created detailed enough to catch this type of scenario? Nope.
Cardspace is fascinating and a solution to many problems but there are some risks that I don't know the answer to. Many enterprises have embraced the notion of an XML firewall be it layer 7, vordel, datapower, etc as the importance of handling secure parsing is something many have gotten burnt by. Now, Cardspace as an approach says lets ignore some of the best practice of XML firewalls and instead put a generic .NET parser on the front lines of our security model. Can Microsoft say that its parsing approach is as secure as Vordel? Would Mark ONeill of Vordel agree?
One way to make Cardspace more secure would be to at least guarantee it isn't subject to the OWASP Top Ten. Imagine being able to perform injection attacks on self-issued cards? Should Microsoft at least consider embedding the OWASP Enterprise Security API as a way to make it better?
Going back to the federation scenario for a moment, we would also need to consider the fact that federation products tend to be separate and distinct from web access management products. So, in this scenario the application wouldn't even have an opportunity to protect itself as the federation product would simply create a cookie and not pass context as to how this user was authenticated.
More interesting is the fact that even if the federation products wanted to pass it along to applications, there is no standard way of doing this. So, how would Ping Identity pass along the fact to Netegrity Siteminder that I signed on via federation? Does this mean that standards need to exist in the web access management space? Should Oblix, OpenSSO and others address this?