Thursday, April 30, 2009
I will be presenting at a Ruby User Group on the topic of enterprise readiness
Some of the things that I have concluded is that Ruby is starting to gain traction and should be enterprise ready by 2011. In comparing its value proposition to Smalltalk, Ruby now has more potential...
| | View blog reactions
Wednesday, April 29, 2009
Open Source DRM
| | View blog reactions
Unemployed IT Professionals in the Northeast
Many IT professionals have yet to figure out that there are lots of jobs in IT security and they can position themselves for it by attending their local OWASP meetings...
The next meeting for the Hartford chapter of OWASP is on June 10th and addition to our usual great topics on web application security, we will be inviting in recruiters from several large enterprises who will be sharing their current job openings.
This meeting will feature Marcus Ranum, inventor of the first firewall.
This event is 100% free to attend. Subscribe to the mailing list to receive updates on future meetings: http://lists.owasp.org/mailman/listinfo/owasp-hartford
| | View blog reactionsThe next meeting for the Hartford chapter of OWASP is on June 10th and addition to our usual great topics on web application security, we will be inviting in recruiters from several large enterprises who will be sharing their current job openings.
This meeting will feature Marcus Ranum, inventor of the first firewall.
This event is 100% free to attend. Subscribe to the mailing list to receive updates on future meetings: http://lists.owasp.org/mailman/listinfo/owasp-hartford
Tuesday, April 28, 2009
Retirement from the Blogosphere: July 4th 2009
I previously announced that I would be regaining my independent on July 4th and will stop blogging. I have been noodling what should be my final topic. Should I post my own departing thoughts or should I simply respond to questions that others would like to know?
| | View blog reactionsIdentity Federation and Management
Now that Sun is owned by Oracle, I wonder if Pat Patterson will be making an announcement at the European Identity Conference on whether OpenSSO will survive against Oracle's own Oracle Identity Federation (OIF) product suite it spent money acquiring from Oblix?
Oracle and Sun had competing technologies in the identity provisioning space as well. Migration between these two tool suites is non-trivial, but if one tool will loose the battle, it will become important to think more about standards such as SPML as an isolation layer vs attempting to deal with even more custom adapters.
The strategy around how identity management evolves in the enterprise is actually a more important conversation than whether Oracle decides to keep products around. I suspect that many within the enterprise have done a horrific job of making their identity management implementations other than tightly coupled. Maybe, we need some discussions in the blogosphere on IdM and looser coupling to enterprise applications...
| | View blog reactionsOracle and Sun had competing technologies in the identity provisioning space as well. Migration between these two tool suites is non-trivial, but if one tool will loose the battle, it will become important to think more about standards such as SPML as an isolation layer vs attempting to deal with even more custom adapters.
The strategy around how identity management evolves in the enterprise is actually a more important conversation than whether Oracle decides to keep products around. I suspect that many within the enterprise have done a horrific job of making their identity management implementations other than tightly coupled. Maybe, we need some discussions in the blogosphere on IdM and looser coupling to enterprise applications...
Monday, April 27, 2009
Did you know that SCRUM increases failure in many large enterprises...
In reading many of the internet musings about Scrum from evangelists, cynics and everyone in between, three common and somewhat contradictory themes have stood out to me:
1. Scrum implementation fails because the processes of Scrum are not followed closely enough.
2. Scrum implementation fails because the organization does not adapt Scrum to its own environment/culture/practices.
3. The processes of Scrum are not important; only the values in the Agile Manifesto matter.
Many enterprisey types miss one of the key components of agility which is to release early and often. To the degree that you don't do this, your process is not agile and bound to suffer the same sorts of problems that traditional, plan-driven processes have. It may be that this is a temporary condition as you are just getting used to things, but you need to start releasing soon (and regularly). Remember, working software is the primary measure of progress. Putting documents on sharepoints and other traditional waterfall practices are not releases.
| | View blog reactions1. Scrum implementation fails because the processes of Scrum are not followed closely enough.
2. Scrum implementation fails because the organization does not adapt Scrum to its own environment/culture/practices.
3. The processes of Scrum are not important; only the values in the Agile Manifesto matter.
Many enterprisey types miss one of the key components of agility which is to release early and often. To the degree that you don't do this, your process is not agile and bound to suffer the same sorts of problems that traditional, plan-driven processes have. It may be that this is a temporary condition as you are just getting used to things, but you need to start releasing soon (and regularly). Remember, working software is the primary measure of progress. Putting documents on sharepoints and other traditional waterfall practices are not releases.
More thoughts on Identity Based Encryption
Awhile back, I blogged on Identity Based Encryption and wanted to share additional thoughts...
Next week is the start of what I predict will be one of the most meaningful conferences to occur on the planet. The European Identity Conference will feature the likes of Pat Patterson, Jackson Shaw, Kim Cameron, Luther Martin, David Kearns and other thought leaders all under one roof talking about all things identity related. Anyway, I am sitting here thinking about identity and this reminded me of identity-based encryption.
Identity Based Encryption really isn't about encryption but is more about key management. Encryption is an easier topic on many levels than key management and I believe that IBE attempts to sweep the difficulties associated under the rug. Trying to use identity as the foundation is fraught with problems, because no one has a really good solution to verifying identity in electronic applications, whether on the net or in the physical world. Without a good solution to identity, these IBE schemes fall on their face once you stress the identities they rely on.
Most of the IBE systems discussed in the wild lack the technical thought leadership necessary and simply devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
The problem is that you have to have a way of generating and managing those keys, and that turns out to be hard, because the scheme is only as good as the protection you have on your private key. There are a number of methods for doing this.
ID based encryption attempts to simplify this key management problem by proposing special algorithms that construct private keys from a known public piece of information: say an email address. To do this in a way that still makes it hard to figure out the private side, you need to have a trusted entity who constructs the private key based on some other secret they know. So, to establish your communications with someone who knows your email address. you go to the trusted provider and ask for the private key to be generated. The person you want to communicate with knows what provider you use, and gets a master public key from that provider.
Now, the person you want to send to can then generate the public side from your ID without knowing anything except some master key information from the provider; the key is never transmitted direction.
In other words, it looks like this: Alice wants to send email to Bob that's encrypted. They both trust a provider, Tom.
Alice sends a request to Tom with her email address "alice@example.com", and gets back a private key P. There is a corresponding public key p, but Tom doesn't send that to anyone.
Bob sends a request to Tom and gets Tom's master public key m.
Alice encrypts her message "x" with her private key, giving {"x"}P. (That notation is just "message "x" "wrapped" or encryption with key P.) Alice then sends that message to Bob.
Bob uses his knowledge of Alice's email address and Tom's master key m, and computes. p=f("alice@example.com", m). Now he applies the decryption decrypt({"x")P, p) and poof, out comes Alice's message.
The thing about these schemes is that it simplifies some key management issues, but only somewhat. You still need to generate the keys, and what's worse, you have to really trust Tom, because he knows everything: he can generate your private key, and encrypt with it, making any message look like it came from you. What this means is that it creates an inherent key escrow scheme; your private key can be found out.
Most of the IBE systems I've seen any technical detail about really devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
Modern cryptography is all about searching for ways to not have to rely on the third party. Web of trust is one approach, the main drawback is that it leaves key management to the end users. The solution is not to make key management more expensive but to reduce the process and practices around it.
Traditional PKI approaches rely on certificate issuers where there is clarity on who the certificate issuers are and are known trusted third parties by all. A few years ago, one of the major issues that all the browsers trusted went bust and was bought out of bankruptcy by a player who wasn't obviously trustworthy, making it clear that the weakness in that scheme is at the root of the certificate chains.
| | View blog reactionsNext week is the start of what I predict will be one of the most meaningful conferences to occur on the planet. The European Identity Conference will feature the likes of Pat Patterson, Jackson Shaw, Kim Cameron, Luther Martin, David Kearns and other thought leaders all under one roof talking about all things identity related. Anyway, I am sitting here thinking about identity and this reminded me of identity-based encryption.
Identity Based Encryption really isn't about encryption but is more about key management. Encryption is an easier topic on many levels than key management and I believe that IBE attempts to sweep the difficulties associated under the rug. Trying to use identity as the foundation is fraught with problems, because no one has a really good solution to verifying identity in electronic applications, whether on the net or in the physical world. Without a good solution to identity, these IBE schemes fall on their face once you stress the identities they rely on.
Most of the IBE systems discussed in the wild lack the technical thought leadership necessary and simply devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
The problem is that you have to have a way of generating and managing those keys, and that turns out to be hard, because the scheme is only as good as the protection you have on your private key. There are a number of methods for doing this.
ID based encryption attempts to simplify this key management problem by proposing special algorithms that construct private keys from a known public piece of information: say an email address. To do this in a way that still makes it hard to figure out the private side, you need to have a trusted entity who constructs the private key based on some other secret they know. So, to establish your communications with someone who knows your email address. you go to the trusted provider and ask for the private key to be generated. The person you want to communicate with knows what provider you use, and gets a master public key from that provider.
Now, the person you want to send to can then generate the public side from your ID without knowing anything except some master key information from the provider; the key is never transmitted direction.
In other words, it looks like this: Alice wants to send email to Bob that's encrypted. They both trust a provider, Tom.
The thing about these schemes is that it simplifies some key management issues, but only somewhat. You still need to generate the keys, and what's worse, you have to really trust Tom, because he knows everything: he can generate your private key, and encrypt with it, making any message look like it came from you. What this means is that it creates an inherent key escrow scheme; your private key can be found out.
Most of the IBE systems I've seen any technical detail about really devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
Modern cryptography is all about searching for ways to not have to rely on the third party. Web of trust is one approach, the main drawback is that it leaves key management to the end users. The solution is not to make key management more expensive but to reduce the process and practices around it.
Traditional PKI approaches rely on certificate issuers where there is clarity on who the certificate issuers are and are known trusted third parties by all. A few years ago, one of the major issues that all the browsers trusted went bust and was bought out of bankruptcy by a player who wasn't obviously trustworthy, making it clear that the weakness in that scheme is at the root of the certificate chains.
Adventures of an Eternal Optimist
Chris swan shared a link with me on the experiences of Pamela Dingle and her attempts to attend the RSA conference that I thought was fascinating...
Let's analyze her posting to see if new insights emerge:
| | View blog reactionsLet's analyze her posting to see if new insights emerge:
- I didn’t purchase a conference pass — frankly, I couldn’t, I have just started a new business, and the fiscal reality involved in that activity forced me to be thrifty.
- Being on the outside, however, taught me that while the tracks were inside, the PEOPLE weren’t always, and that in fact by ditching any illusory pretension to education, taking advantage of the Concordia workshop for which entrance only required an expo pass, walking the expo floor, and attending the parties, I didn’t miss the expensive & time-consuming sessions.
- I am usually the most avid attendee at these things, asking a lot of questions and generally participating enthusiastically (ask anyone).
- I’m sure this doesn’t have you crying in your cheerios at the thought of the loss; but I suggest you examine the trend it represents; it is why you want the movers and the shakers *inside* the conference hall, not outside, as often as possible.
Sunday, April 26, 2009
In order to adopt Agile, do you have to divest team members from their respective skills?
As enterprises start to experiment with introducing agile methods, skill sets are becoming blurred and people will over time receive less respect for their individual abilities...
Some developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other but they are certainly different.
While agile should encourage developers to learn new skills, many simply get better at becoming mediocre and never master another skill. If you have telecommuters involved, they will get even further blurred as managing remote workers is not a skill that many PMs have in their toolbelt and agile makes it more difficult. PMs can either bury resources where they give preferential treatment to those who manage face time or simply give those not in sight menial tasks that they don't have to track (aka busy work).
While I know that many will have a different perspective, I am curious to hear from those who had different experiences...
| | View blog reactionsSome developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other but they are certainly different.
While agile should encourage developers to learn new skills, many simply get better at becoming mediocre and never master another skill. If you have telecommuters involved, they will get even further blurred as managing remote workers is not a skill that many PMs have in their toolbelt and agile makes it more difficult. PMs can either bury resources where they give preferential treatment to those who manage face time or simply give those not in sight menial tasks that they don't have to track (aka busy work).
While I know that many will have a different perspective, I am curious to hear from those who had different experiences...
European Identity Conference 2009
The European Identity Conference is the place to meet with enterprise technologists, thought leaders and experts to learn about, discuss and shape the market in most significant technology topics such as Identity Management, Governance, Risk Management and Compliance (GRC) and Service Oriented Architecture (SOA).
I attend a lot of conferences but this is the one that I am looking forward to attending the most in 2009. If you will be in attendance and want to hook up, trackback. I hope to meet up with many enterprise architecture practitioners in Europe and hope to trade notes..
| | View blog reactionsI attend a lot of conferences but this is the one that I am looking forward to attending the most in 2009. If you will be in attendance and want to hook up, trackback. I hope to meet up with many enterprise architecture practitioners in Europe and hope to trade notes..
Saturday, April 25, 2009
Enterprise Architecture: Quote of the Week
Too many people seem to think that documentation is the "final" argument. It's not. Not even close. It's a hint and a help, but it's _secondary_ to code. Anybody who doesn't understand that should never be allowed to write code (or documentation, for that matter).
-- Linus Torvalds
| | View blog reactions-- Linus Torvalds
Friday, April 24, 2009
Enterprise Architecture: How to guarantee outsourcing failure...
I have developed a reputation for bashing Indian outsourcing without necessarily taking a look at the worst practices in the United States. Today's blog entry focuses on one that I believe accounts for the majority of failure...
So, how do we align what's best for our employers while not sacrificing what is best for our wallets?
| | View blog reactions
Imagine you are responsible for outsourcing a particular function within in a company... Now, the outsourcing has been going well, but it's time for a contract renewal. Will your employer thank you for simply renewing and keeping things the same, and thus keeping the service running well? Unlikely.
More likely, you'll get your bonus only if you:
- screw your supplier into the ground by demanding a huge reduction in rates (leading to poorer service)
- decide to move the contract to another provider (potentially leading to poorer service
- make some other big change e.g. insourcing.
So, how do we align what's best for our employers while not sacrificing what is best for our wallets?
Thursday, April 23, 2009
Are Europeans smarter than Americans when it comes to outsourcing?
For the time being the best outsourcing location is Eastern Europe. Especially for companies from Western Europe as there is no time shift, there is no much cultural difference, there are all the possibilities to communicate and travel to each other etc. But still there is a nice price difference for outsourcing to be appealing.
Just as an example of smart outsourcing - if you are a company from Sweden, what would be the right choice for you to outsource to? Naturally, it would be a country like Lithuania or nearby. As the location is pretty close but the price difference is two times.
I wonder why American's let Europeans have such a competitive advantage while we have the ability to pull off an even better deal by outsourcing to Jamaica, Trinidad or other Caribbean islands...
| | View blog reactionsJust as an example of smart outsourcing - if you are a company from Sweden, what would be the right choice for you to outsource to? Naturally, it would be a country like Lithuania or nearby. As the location is pretty close but the price difference is two times.
I wonder why American's let Europeans have such a competitive advantage while we have the ability to pull off an even better deal by outsourcing to Jamaica, Trinidad or other Caribbean islands...
Links for 2009-04-23
Do you agree?
Someone likes the latest Gary McGraw podcast
Increasing productivity when times are tough and you don't have money as a tool is something most executives are clueless about.
This problem can only be solved with Barack Obama style governance. If he can get the CEO of GM fired, then I wonder if firing executives who lose data is the next best idea.
Hopefully folks on my side of town are aware of the don't drink the water scandal.
This is the place where all the cool IT professionals hang out.
Wednesday, April 22, 2009
Enterprise Architecture: CMMi is evil...
Is the goal of CMMI to create consistent suckage...
How many times in your career have you ran across an enterprise architect who is an employee of a Fortune enterprise where they were advocates of CMMI?
Long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all (with the exception of folks doing Indian Outsourcing and others who have zero clue about anything).
Of course one cannot simply state that CMM is evil. Making that statement without an auditable artifact flow is against evil best practice. Please create an Evil Requirements Definition document to be submit to an Evil Review Committee as directed in the Evil Development Life Cycle Manual. Once you have obtained the appropriate signatures of the Evil Personnel, you can begin to prepare and Evil Design Document that must be reviewed not once but at least twice. Once you have completed and Evil Preliminary Design Review and an Evil Critical Design Review and again received the necessary Evil Signatures, you can begin to develop your Evil Statement. Once complete, you will have to submit your Evil Statement to an Evil Independent Test consisting of testers who do not know what Evil is but have read through your Evil Requirements Definition.
Of course, you can be Agile and Evil. Evil is flexible. Feel free to generate your own tailored versions of the thousands of pages of standard Evil Procedures. These will be carefully reviewed by the Evil Process Waiver Committee and rejected after wasting even more time and effort.
| | View blog reactionsHow many times in your career have you ran across an enterprise architect who is an employee of a Fortune enterprise where they were advocates of CMMI?
Long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all (with the exception of folks doing Indian Outsourcing and others who have zero clue about anything).
Of course one cannot simply state that CMM is evil. Making that statement without an auditable artifact flow is against evil best practice. Please create an Evil Requirements Definition document to be submit to an Evil Review Committee as directed in the Evil Development Life Cycle Manual. Once you have obtained the appropriate signatures of the Evil Personnel, you can begin to prepare and Evil Design Document that must be reviewed not once but at least twice. Once you have completed and Evil Preliminary Design Review and an Evil Critical Design Review and again received the necessary Evil Signatures, you can begin to develop your Evil Statement. Once complete, you will have to submit your Evil Statement to an Evil Independent Test consisting of testers who do not know what Evil is but have read through your Evil Requirements Definition.
Of course, you can be Agile and Evil. Evil is flexible. Feel free to generate your own tailored versions of the thousands of pages of standard Evil Procedures. These will be carefully reviewed by the Evil Process Waiver Committee and rejected after wasting even more time and effort.
Thoughts on the Sun and Oracle
Every industry analyst has expressed an uninformed opinion on Sun and Oracle and figured that I should be equally irresponsible...
Talking about products all day doesn't get me excited. What does is the possibility that Sun may be afforded the opportunity to fix deficiencies in their culture. I have met many Sun employees whom I thought were bright but otherwise constrained in their ability to do meaningful things like interact with customers in a proper way.
Many Sun employees are on mailing lists and are passionate about blogging but yet never find enough ways to interact with customers on a face-to-face basis. For example, in the Hartford CT area, you can find user groups for developers being run by Microsoft, Oracle and other large vendors. What you won't find is a single event that is ever sponsored by Sun targeted at this demographic.
So, we all know that support via mailing lists is a great characteristic but this usually matters only until after you become a customer. Sun simply doesn't do enough before you are one. Likewise, folks understand that I am passionate about building security in and believe that software companies need to have static analysis tools in their portfolio to provide secure code review capabilities. If you were to take a look at the top ten enterprise software vendors, Sun is the only vendor to not have any deep capabilities to review their own code. At some level, they rely on smart people but this isn't a sustainable model.
Oracle's culture doesn't suffer from any of the above deficiencies and if they get the acquisition right, it could be 1 + 1 = 11. Now for a few predictions:
1. Oracle will dump OpenSSO in three years and stick with OIF.
2. Oracle will keep both OIM and Sun IDM as it is too difficult, costly to migrate customers between them.
3. Oracle had a strategy around providing specialized storage capability for Oracle databases. This strategy can now be flushed as they were working with HP on it.
4. Sun employees would do themselves a big favor by being proactive and pursuing their own startups. Think about writing those business plans you dreamed about and getting funding for them. The bloodbath is imminent.
5. The employees within Sun who will survive will not only be the better engineers, but the ones who understand the mindset of those within large enterprises. I suggest Sun employees start reading enterprise architecture books in their spare time.
6. The biggest bloodbath will occur with Sun employees in India...
| | View blog reactionsTalking about products all day doesn't get me excited. What does is the possibility that Sun may be afforded the opportunity to fix deficiencies in their culture. I have met many Sun employees whom I thought were bright but otherwise constrained in their ability to do meaningful things like interact with customers in a proper way.
Many Sun employees are on mailing lists and are passionate about blogging but yet never find enough ways to interact with customers on a face-to-face basis. For example, in the Hartford CT area, you can find user groups for developers being run by Microsoft, Oracle and other large vendors. What you won't find is a single event that is ever sponsored by Sun targeted at this demographic.
So, we all know that support via mailing lists is a great characteristic but this usually matters only until after you become a customer. Sun simply doesn't do enough before you are one. Likewise, folks understand that I am passionate about building security in and believe that software companies need to have static analysis tools in their portfolio to provide secure code review capabilities. If you were to take a look at the top ten enterprise software vendors, Sun is the only vendor to not have any deep capabilities to review their own code. At some level, they rely on smart people but this isn't a sustainable model.
Oracle's culture doesn't suffer from any of the above deficiencies and if they get the acquisition right, it could be 1 + 1 = 11. Now for a few predictions:
1. Oracle will dump OpenSSO in three years and stick with OIF.
2. Oracle will keep both OIM and Sun IDM as it is too difficult, costly to migrate customers between them.
3. Oracle had a strategy around providing specialized storage capability for Oracle databases. This strategy can now be flushed as they were working with HP on it.
4. Sun employees would do themselves a big favor by being proactive and pursuing their own startups. Think about writing those business plans you dreamed about and getting funding for them. The bloodbath is imminent.
5. The employees within Sun who will survive will not only be the better engineers, but the ones who understand the mindset of those within large enterprises. I suggest Sun employees start reading enterprise architecture books in their spare time.
6. The biggest bloodbath will occur with Sun employees in India...
Tuesday, April 21, 2009
If your wife were a relational database...
SELECT wife FROM women WHERE
looks=gorgeous AND idealman LIKE 'James'
UNION
SELECT husband FROM men WHERE
job=geek AND loves=Sherry
| | View blog reactionslooks=gorgeous AND idealman LIKE 'James'
UNION
SELECT husband FROM men WHERE
job=geek AND loves=Sherry
Monday, April 20, 2009
Enterprise Architecture: Why inhouse applications are difficult to maintain...
We all know that Enterprise applications that were developed inhouse cost more per line of code to maintain than applications developed by commercial software vendors, but have never considered the factors as to why...
Commercial software development has an advantage over inhouse developed applications along the lines of the ability to maintain conceptual integrity. Requirements are normalized across many different demographics where inhouse developed applications are not.
Within enterprise applications, business rules are often determined by high-level managers and the marketing department. There may not be any apparent logical or rational to many of them from the developer's perspective and asking for it may not be an option. Marketers tend to be "intuitive" thinkers which often drives analytical geeks nuts.
Inhouse applications unlike commercial software have encoded within them, the personality(s) rather than physical or mathematical truths. Enterprise architects struggle to rationalize and devise roadmaps where predicting the future of them gets more difficult as time passes.
| | View blog reactionsCommercial software development has an advantage over inhouse developed applications along the lines of the ability to maintain conceptual integrity. Requirements are normalized across many different demographics where inhouse developed applications are not.
Within enterprise applications, business rules are often determined by high-level managers and the marketing department. There may not be any apparent logical or rational to many of them from the developer's perspective and asking for it may not be an option. Marketers tend to be "intuitive" thinkers which often drives analytical geeks nuts.
Inhouse applications unlike commercial software have encoded within them, the personality(s) rather than physical or mathematical truths. Enterprise architects struggle to rationalize and devise roadmaps where predicting the future of them gets more difficult as time passes.
Sunday, April 19, 2009
Agile Manifesto 2.0
- Make business aware of programming and programmers aware of business
- Accept the reality of change and embrace it rather than resist it
- Personal responsibility beats external control
- Structure is essential to success, but heavy bureaucracy is not
- Software development should occur via empirical process control rather than defined process control
- Planning is everything, but the plan is simply the starting point
- Perception management is important, treating others like they are human and rewarding them for their dedication and integrity is more important
| | View blog reactions- Accept the reality of change and embrace it rather than resist it
- Personal responsibility beats external control
- Structure is essential to success, but heavy bureaucracy is not
- Software development should occur via empirical process control rather than defined process control
- Planning is everything, but the plan is simply the starting point
- Perception management is important, treating others like they are human and rewarding them for their dedication and integrity is more important
Saturday, April 18, 2009
Enterprise Architecture, SCRUM and Agile Ceremonies
What happens when you combine the thinking of enterprise architecture with partial adoption of SCRUM, you get something along the lines of making chocolate chip cookies but without the chocolate chips...
I was talking to an architect down the road and realized that the buzzword of SCRUM is the latest word to be abused in large enterprises. When folks are talking about SCRUM, they are talking about socialization constructs and not necessarily management practices. All of the agile methods advocate the principle that everything is important but something is more important yet most enterprise architects have no framework that guides them in this regard.
The interesting observation I have noted is that the enterprise architects that still dabble in code have a fundamentally different perspective on the enterprise version of SCRUM than those who no longer code. One can find the results of enterprise SCRUM processes to feel a lot like cowboy coding where folks downstream areforcedencouraged to maintain 200,000 lines of undocumented comment-free code.
SCRUM is also used to hold enterprise participants hostage. Getting off a project that you didn't much care for to work on something fun, only to be repeatedly dragged back for firefighting is amplified since it requires co-location. The enterprise decision making process has always been sporadic but enterprise scrum makes this even worse. I bet you may have noticed that many of the technical decisions in enterprise scrum are made by the least technical person...
| | View blog reactionsI was talking to an architect down the road and realized that the buzzword of SCRUM is the latest word to be abused in large enterprises. When folks are talking about SCRUM, they are talking about socialization constructs and not necessarily management practices. All of the agile methods advocate the principle that everything is important but something is more important yet most enterprise architects have no framework that guides them in this regard.
The interesting observation I have noted is that the enterprise architects that still dabble in code have a fundamentally different perspective on the enterprise version of SCRUM than those who no longer code. One can find the results of enterprise SCRUM processes to feel a lot like cowboy coding where folks downstream are
SCRUM is also used to hold enterprise participants hostage. Getting off a project that you didn't much care for to work on something fun, only to be repeatedly dragged back for firefighting is amplified since it requires co-location. The enterprise decision making process has always been sporadic but enterprise scrum makes this even worse. I bet you may have noticed that many of the technical decisions in enterprise scrum are made by the least technical person...
Friday, April 17, 2009
Enterprise Architecture: Are hybrid approaches always useful?
Two guys are in a room discussing enterprise architecture. One is extremely overweight yet desires to be a horse jockey while the other is short and skinny and desires to play basketball in the NBA. The answer emerges where they eschew common sense for a hybrid solution...
The notion of conceptual integrity is a lost concept in most minds of enterprise architecture where consensus rules the day. We so often compromise on core principles and then wonder why things go awry down the road.
Can the enterprise be truly competitive if decisions are made on facts and logic where perception management is more important? Lately I have been brainstorming PCI compliance and believe that the best way to comply may be to create a company policy that states all servers in the datacenter will be immediately turned off upon the arrival of auditors.
I bet you didn't know that PCI/DSS requires code review as part of its process but doesn't require its auditors to even know how to code? Even if this requirement were put there, PCI only spends an entire fifteen minutes teaching its auditors how to look for worst practices.
This reminds me that I need to bullshit a few process weenies I know and convince them I did a proper code review. Maybe I can ask my seven and four year old sons to bless my code just before heading out the door to Chuck E. Cheeses. I bet they will be real thorough...
| | View blog reactionsThe notion of conceptual integrity is a lost concept in most minds of enterprise architecture where consensus rules the day. We so often compromise on core principles and then wonder why things go awry down the road.
Can the enterprise be truly competitive if decisions are made on facts and logic where perception management is more important? Lately I have been brainstorming PCI compliance and believe that the best way to comply may be to create a company policy that states all servers in the datacenter will be immediately turned off upon the arrival of auditors.
I bet you didn't know that PCI/DSS requires code review as part of its process but doesn't require its auditors to even know how to code? Even if this requirement were put there, PCI only spends an entire fifteen minutes teaching its auditors how to look for worst practices.
This reminds me that I need to bullshit a few process weenies I know and convince them I did a proper code review. Maybe I can ask my seven and four year old sons to bless my code just before heading out the door to Chuck E. Cheeses. I bet they will be real thorough...
Thursday, April 16, 2009
Team OWASP on Kiva
Kiva is a non-profit website that allows you to lend as little as $25 to a specific low-income entrepreneur in the developing world. You choose who to lend to - whether a baker in Afghanistan, a goat herder in Uganda, a farmer in Peru, a restaurateur in Cambodia, or a tailor in Iraq - and as they repay the loan, you get your money back.
Check out the OWASP lending team, and learn more about lending teams on Kiva in general, by clicking here.
I haven't had anyone yet join from Gartner, IBM or EMC...
| | View blog reactionsCheck out the OWASP lending team, and learn more about lending teams on Kiva in general, by clicking here.
I haven't had anyone yet join from Gartner, IBM or EMC...
Wednesday, April 15, 2009
Enterprise Architecture: You are NOT management material...
Here are a few ways of determining whether you are management material...
You envy the developers under you instead of your own boss.
When the CEO asks whose fault it is that the project is late, you say, "Yours, Sir"
You use statistics and facts in meetings instead of overdistilled generalizations
When you go out and get drunk at night with your boss, you break down and start crying about how much you love Java
You try to explain to the CEO how the company will capture a new market by drawing a UML Interaction diagram.
You hold as important the needs of the consumer and the quality of what is produced for them over the magnitude of the bottom line
You can personally "sign" your work with pride
| | View blog reactionsTuesday, April 14, 2009
Enterprise Architecture: When good people get fired...
Most employees in the US can have their employment terminated by their employers at any time, for almost any reason...
Recently, I have heard many people talk about being fired. Some feel that the modern approach to management differs from being human (at some level I agree) but also without acknowledging all of the factors that go into a firing decision. So, I decided to outline some things to noodle.
Because employees cannot count on their jobs being around forever, employees need to take control of their careers and their economic security. If you save your money, keep your skills up to date, and maintain contacts outside your company, then being fired should not be a disaster. Don't become too economically dependent upon your employer, and don't let your self-esteem or sense of well-being be too closely connected to your job...
| | View blog reactionsRecently, I have heard many people talk about being fired. Some feel that the modern approach to management differs from being human (at some level I agree) but also without acknowledging all of the factors that go into a firing decision. So, I decided to outline some things to noodle.
- Employers don't want to pay the cost associated with replacing employees, but eliminating employees is usually considered to be a cost-saving measure. This is why you see competent people let go while incompetent ones remain. All depends on deployment.
- People are not fired only for incompetence or low productivity. Employers fire people for a lot of reasons: economic conditions, cancellation of a project, elimination of part of the organization, changes in marketing strategy, personality conflicts, managerial whims, etc. Employers have the same right to be stupid that everyone else has and may fire their best people when they are needed most.
- firing can be based on trivial factors, such as a single unauthorized telephone call, being five minutes late one day, number of lines of code written in the past week, etc.
Because employees cannot count on their jobs being around forever, employees need to take control of their careers and their economic security. If you save your money, keep your skills up to date, and maintain contacts outside your company, then being fired should not be a disaster. Don't become too economically dependent upon your employer, and don't let your self-esteem or sense of well-being be too closely connected to your job...
Monday, April 13, 2009
Enterprise Architecture and the Federal Government
Now that we have a new Government CIO, I figured I would share some thoughts on making it better...
Encourage more personnel churn. There is often too much ossification in government.
Don't make the job application process so cumbersome that productivity-minded people give up or are frightened away.
More subordinate evaluation of supervisors would help immensely. There are too many supervisors with huge flaws that never get checked because their superiors don't see it or don't care.
Encourage Federal Government employees to participate in OWASP.
Mandate that government contractors use methodologies such as Extreme Programming and SCRUM.
Allow for all belief systems to be fair game for questioning.
| | View blog reactionsOWASP Hartford: April 2009
Want to learn about Agile, CMMI, Extreme Programming, SCRUM or other software development topic? Scott Ambler will be speaking at OWASP Hartford tonight (Monday, April 13th) as part of a special session. If you would like to attend, drop me a note at my work email...
| | View blog reactionsSunday, April 12, 2009
Time to make it short...
I have made this blog entry longer than usual because I lack the time to make it shorter.
Saturday, April 11, 2009
How low quality is the software your enterprise writes?
Has anyone ever ran across high-quality internally-developed enterprise software? When software isn't consumed by third-parties, then quality can be order of magnitudes lower in quality...
So, if quality can be lower in enterprise inhouse software, then that allows for lower-quality resources from Indian outsourcing firms to maintain it. Remember that good is good enough and it doesn't make sense for architects to expend such energy churning on better ways of developing higher quality working software.
Indian outsourcing has caused many to lower their standards and therefore the opportunity to abuse is rampant. Methodologies such as extreme programming encourage merciless refactoring while indian outsourcing has taught us that refactoring is nothing but overhead as you have to write comprehensive documentation in order to get working software. Sometimes the effort but into documentation makes refactoring a non-starter.
Refactoring in code isn't overhead, any more than writing a first draft is overhead in writing a book. It's an inherent part of one of the best ways of producing good code, just as writing drafts is an inherent part of one of the best ways of producing a good book.
American IT professionals have lost the battle because they argued the quality front which no longer matters...
| | View blog reactionsSo, if quality can be lower in enterprise inhouse software, then that allows for lower-quality resources from Indian outsourcing firms to maintain it. Remember that good is good enough and it doesn't make sense for architects to expend such energy churning on better ways of developing higher quality working software.
Indian outsourcing has caused many to lower their standards and therefore the opportunity to abuse is rampant. Methodologies such as extreme programming encourage merciless refactoring while indian outsourcing has taught us that refactoring is nothing but overhead as you have to write comprehensive documentation in order to get working software. Sometimes the effort but into documentation makes refactoring a non-starter.
Refactoring in code isn't overhead, any more than writing a first draft is overhead in writing a book. It's an inherent part of one of the best ways of producing good code, just as writing drafts is an inherent part of one of the best ways of producing a good book.
American IT professionals have lost the battle because they argued the quality front which no longer matters...
Friday, April 10, 2009
Industry Analysts and Federated Identity
I was thinking that I haven't worked with any industry analyst firm in a long term in terms of allowing them to create a case study on things we do well. I wonder if there is interest in learning about what me and my employer are up to in the world of federated identity?
| | View blog reactionsExplaining Security to Business People
The vast majority of IT security professionals in large enterprises don't usually interact with the business community and therefore don't know how to convince them that well-established encryption algorithms, well-established key exchange protocols, etc, will be much better than whatever homebrew scheme they cook up themselves in a couple of meetings...
Not invented here is a common attitude in many enterprises when it comes to many things but security is even more challenging in that it requires others to acknowledge that their thinking is incomplete and adhoc schemes are not enough before they are willing to spend time and effort to quantify additional requirements.
Security is a business issue and many decisions should be made by business people, however there is no framework that helps business people who generally aren't as passionate as IT in seeking enlightenment to participate and make informed decisions. Imagine what would happen if business customers came up with their own scheme to implement either disaster recovery and/or high availability? They will probably come up with ways that are either expensive and ineffective, or simple and ineffective. There are many ways to handle HA/DR requirements but usually you have to specify the need before you can decide how to do it.
So, what are security professionals not doing that HA/DR types have figured out? Maybe this can be a conversation at an upcoming OWASP conference?
| | View blog reactionsNot invented here is a common attitude in many enterprises when it comes to many things but security is even more challenging in that it requires others to acknowledge that their thinking is incomplete and adhoc schemes are not enough before they are willing to spend time and effort to quantify additional requirements.
Security is a business issue and many decisions should be made by business people, however there is no framework that helps business people who generally aren't as passionate as IT in seeking enlightenment to participate and make informed decisions. Imagine what would happen if business customers came up with their own scheme to implement either disaster recovery and/or high availability? They will probably come up with ways that are either expensive and ineffective, or simple and ineffective. There are many ways to handle HA/DR requirements but usually you have to specify the need before you can decide how to do it.
So, what are security professionals not doing that HA/DR types have figured out? Maybe this can be a conversation at an upcoming OWASP conference?
Thursday, April 09, 2009
Are you married to Enterprise Architecture?
If you really love someone, then you'll stick around and take advantage of the ways they're wonderful, and you'll try to ignore, improve, or mitigate the ways they're awful. But if your husband starts slapping you around, it's time to leave. Too many folks let themselves be slapped around...
You have a certain realtionship with your employer. You also have a relationship with your lover, your children, and your future. When the interests of these parties conflict, this may manifest itself as dissent within one or several of your relationships. Sometimes we are all consumers of a slow poison that is toxic to everything we do.
So, if enterprise architecture is about people, processes then tools, in that order then how do we determine when we should marry things together and when things should be separated. So, if we were to focus on the people aspects then it would probably mean that we need to focus on poor people management which spreads without conscious effort and can slowly poison others.
Poor managers are poor managers for a reason: fear, distrust, ignorance, etc. Over time, they will actually make decisions that increase these qualities in other people they deal with. This is apparent in most interactions with coworkers, but is exceptionally apparent in personnel decisions, with poor managers hiring, promoting, and otherwise rewarding subordinates with dysfunctions that complement their own. The classic example is trusting only a "yes-man", who will agree with every decision you make regardless of the quality of the decision itself.
In addition to rewarding and spreading mismanagement, this will also drive out motivated, conscientious intelligent workers, who will at some point realize it makes more sense to focus on organizational change management over committing to other business-oriented strategies. Through this phenomena, an organization can actually get less competent over time, even with other inputs (size, revenue, business climate, etc.) remaining constant.
Mismanagement can destroy an entire organization, but it can happen so slowly that the managers might not notice it or are likely to misunderstand why the organization is failing. So the feedback loop is not very tight, and they can either avert their gaze from the growing problem or they can find scape goats.
| | View blog reactionsYou have a certain realtionship with your employer. You also have a relationship with your lover, your children, and your future. When the interests of these parties conflict, this may manifest itself as dissent within one or several of your relationships. Sometimes we are all consumers of a slow poison that is toxic to everything we do.
So, if enterprise architecture is about people, processes then tools, in that order then how do we determine when we should marry things together and when things should be separated. So, if we were to focus on the people aspects then it would probably mean that we need to focus on poor people management which spreads without conscious effort and can slowly poison others.
Poor managers are poor managers for a reason: fear, distrust, ignorance, etc. Over time, they will actually make decisions that increase these qualities in other people they deal with. This is apparent in most interactions with coworkers, but is exceptionally apparent in personnel decisions, with poor managers hiring, promoting, and otherwise rewarding subordinates with dysfunctions that complement their own. The classic example is trusting only a "yes-man", who will agree with every decision you make regardless of the quality of the decision itself.
In addition to rewarding and spreading mismanagement, this will also drive out motivated, conscientious intelligent workers, who will at some point realize it makes more sense to focus on organizational change management over committing to other business-oriented strategies. Through this phenomena, an organization can actually get less competent over time, even with other inputs (size, revenue, business climate, etc.) remaining constant.
Mismanagement can destroy an entire organization, but it can happen so slowly that the managers might not notice it or are likely to misunderstand why the organization is failing. So the feedback loop is not very tight, and they can either avert their gaze from the growing problem or they can find scape goats.
