Tuesday, February 28, 2006
Even More Questions on Identity
Couldn't resist piling on another thought related to identity. I previously asked several questions on identity and figured one more wouldn't hurt.
Yesterday, Novell and IBM threw their weight behind a framework that uses completely different approach: project Higgins. First, it's an API that aggregates trust providers from many different vendors. For example IBM is planning to use it in its commercial Tivoli identity management software. Programmers can write smart secure applications using these calls and not be locked in to any particular technology or provider.
I wonder what Kim Cameron thinks? Could someone let me know if Sun will join Infocard, Higgins, create their own or just sit on the sidelines...
| | View blog reactionsYesterday, Novell and IBM threw their weight behind a framework that uses completely different approach: project Higgins. First, it's an API that aggregates trust providers from many different vendors. For example IBM is planning to use it in its commercial Tivoli identity management software. Programmers can write smart secure applications using these calls and not be locked in to any particular technology or provider.
I wonder what Kim Cameron thinks? Could someone let me know if Sun will join Infocard, Higgins, create their own or just sit on the sidelines...
Imitation is not strategy...
Having read the Cluetrain Manifesto on several occasions, I started thinking about how other enterprises think of strategy and have concluded that imitation is not strategy...
The Cluetrain Manifesto suggests that marketplaces are conversations yet many enterprise architects never actually have one. Instead they outsource their conversations to industry analysts who "distill" down information to serene four-color chock-a-block eye candy Powerpoint presentations that lack substance. Enterprise architects takes this presentations, so-called research, etc and bring them to meetings where they are further used to shut down meaningful conversation that may occur. The best that can emerge from this practice is that an enterprise can imitate what others have done while ending up with something that is no better than what others before them have accomplished.
It is interesting to see how many enterprise architects I have ran across who have no real ability than to imitate others. You will usually run across many of them at industry conferences. They are passionate about sucking knowledge from others but don't have enough depth to innovate on their own. Many architects are one idea types who have already blown their load earlier in their career and somehow have justified their existence in facilitating conversations of others. Facilitation is also not a strategy but participation can be...
Respected analyst, James Governor of RedMonk mentioned in a past blog entry on the importance of Redmonk hiring analysts who blog. Maybe enterprises should consider adopting a similar strategy.
Having grown up in the hip-hop culture and in my early days listening to Wu-Tang, I remember an earlier video that featured Mariah Carey and O'l Dirty Bastard and wonder if this what enterprise architecture is about. In the video, Mariah who is gorgeous is seen somewhere in Beverly Hills on the very high end of the fashion chain. Likewise, O'l Dirty Bastard is in some slum in the Bronx and looks homeless. Some architect put otherwise two polar opposites together and made it work.
I wonder if I have contributed to the problem of other enterprises by blogging? Maybe the best strategy for other enterprises are to read my blog as well as the blogs of others in Fortune enterprises such as
Scott Mark, Charles Betz, James Tarbell and Robert McIlree who choose not to imitate but to focus on original value-added thinking.
I have never really landed on the elevator pitch as to why I blog but think I am getting closer to the answer. Borrowing a thought from John Seely Brown, I think I am Chief of Confusion, helping people ask the right questions, trying to make a difference through my work- speaking, writing, teaching.
Other enterprise architects at least have acknowledged the importance of education but still seem to commit fatal sins by attempting to turn education into training. The practice of corporate training is important but what is more important is in encouraging rich participation with partners in other parts of the organization, customers and even competitors who are at the edge.
Maybe they should ask themselves one and only one question: How do you learn as much from a partner as you learn from creating something yourself?
| | View blog reactionsThe Cluetrain Manifesto suggests that marketplaces are conversations yet many enterprise architects never actually have one. Instead they outsource their conversations to industry analysts who "distill" down information to serene four-color chock-a-block eye candy Powerpoint presentations that lack substance. Enterprise architects takes this presentations, so-called research, etc and bring them to meetings where they are further used to shut down meaningful conversation that may occur. The best that can emerge from this practice is that an enterprise can imitate what others have done while ending up with something that is no better than what others before them have accomplished.
It is interesting to see how many enterprise architects I have ran across who have no real ability than to imitate others. You will usually run across many of them at industry conferences. They are passionate about sucking knowledge from others but don't have enough depth to innovate on their own. Many architects are one idea types who have already blown their load earlier in their career and somehow have justified their existence in facilitating conversations of others. Facilitation is also not a strategy but participation can be...
Respected analyst, James Governor of RedMonk mentioned in a past blog entry on the importance of Redmonk hiring analysts who blog. Maybe enterprises should consider adopting a similar strategy.
Having grown up in the hip-hop culture and in my early days listening to Wu-Tang, I remember an earlier video that featured Mariah Carey and O'l Dirty Bastard and wonder if this what enterprise architecture is about. In the video, Mariah who is gorgeous is seen somewhere in Beverly Hills on the very high end of the fashion chain. Likewise, O'l Dirty Bastard is in some slum in the Bronx and looks homeless. Some architect put otherwise two polar opposites together and made it work.
I wonder if I have contributed to the problem of other enterprises by blogging? Maybe the best strategy for other enterprises are to read my blog as well as the blogs of others in Fortune enterprises such as
Scott Mark, Charles Betz, James Tarbell and Robert McIlree who choose not to imitate but to focus on original value-added thinking.
I have never really landed on the elevator pitch as to why I blog but think I am getting closer to the answer. Borrowing a thought from John Seely Brown, I think I am Chief of Confusion, helping people ask the right questions, trying to make a difference through my work- speaking, writing, teaching.
Other enterprise architects at least have acknowledged the importance of education but still seem to commit fatal sins by attempting to turn education into training. The practice of corporate training is important but what is more important is in encouraging rich participation with partners in other parts of the organization, customers and even competitors who are at the edge.
Maybe they should ask themselves one and only one question: How do you learn as much from a partner as you learn from creating something yourself?
Monday, February 27, 2006
Open Source Routers
| | View blog reactions
Thoughts on Industry Certification
Philip Hartman is blogging on IT Architect Certification. Figured I should share my own thoughts on this issue...
As an individual whom throughout his career has obtained over seventeen different certifications, I have formed the opinion that some were highly credible while others were meaningless. The best certification process by far as Cisco (I achieved CCNP) while the worst was CISSP.
The following things need to happen in order for certification to be meaningful:
| | View blog reactionsAs an individual whom throughout his career has obtained over seventeen different certifications, I have formed the opinion that some were highly credible while others were meaningless. The best certification process by far as Cisco (I achieved CCNP) while the worst was CISSP.
The following things need to happen in order for certification to be meaningful:
- Vendors alone cannot create certifications. They must enlist the participation of large Fortune enterprises at inception
- Certification exams simply cost too much relative to the benefit. They shouldn't be made into profit centers by vendors to boost training revenue.
- All certifications should only be sponsored by non-profit consortiums and should cost no more than $100 and consist of no more than 100 questions
- The folks who created the exams should have their names and biography displayed publicly. Transparency increases credibility.
- Get a few industry folks especially from the agile community to take these exams. Don't let them make up excuses about the value of them
- Publish the failure rate. If the failure rate is too low then it will lose credibility. Shoot for a 50% failure on first shot.
- Allow for the option of individuals to be published in a central place as being certified. Include some demographic information about them such as country, education and type of employer
Sunday, February 26, 2006
Delusional Oriented Architectures
There is an interesting behavior that occurs in corporate America in which I am curious if I also practice it...
Anytime, a new approach to software development emerges whether it is SOA, CMM or even the principles of the agile manifesto we folks in corporate America go through a mental excercise of aligning any questionable practice done in the past with whatever the new paradigm brings.
For those who work in corporate America, you may have noticed that many mainframers for example are of the belief that for the last 25 years they have been doing many of the things that SOA suggests. Of course the paradigm itself is not really new only that they have been recently collected into a single work and more importantly branded. There is a difference though in SOA thinking being 25 years old vs. a 25 year old system having thought about it from the beginning.
I wonder when industry analysts and other book authors including myself will ever show that folks who are of the believe that they are doing SOA probably aren't. Likewise, I think the same thing needs to occur in terms of agile software development.
While I have done many agile projects before becoming a full-time employee of a Fortune 100 enterprise, I know have a disease known as hybridism. In consensus-oriented architectures, one must take parts of everyone's ideas and make them work. When this is practiced, is the agile or not! I kinda believe that while I have to label this agile in order to champion a larger goal, in all reality I may be lying to myself. I may be encouraging others to also become delusional.
A very wise architect (name intentionally withheld) several days ago provided me with an analogy on corporate behavior. He stated that architects in corporate America are kinda like a pack of dogs. We wander around looking for stuff to bite. When we find a nice tree, we need to heist our legs and add our unique scent...
Maybe the first thing that needs to occur is for agilists to start working with folks in human resources. The trend towards competencies seems to be growing (Competencies are a trap but this is a topic for another blog) so maybe there is an opportunity to practice hybridism by acknowledging personality styles. Can folks be lumped into one of the following categories:
Would love to hear from other bloggers on whether their enterprises also have similar behaviors and whether they believe hybridism is a mental disorder...
| | View blog reactionsAnytime, a new approach to software development emerges whether it is SOA, CMM or even the principles of the agile manifesto we folks in corporate America go through a mental excercise of aligning any questionable practice done in the past with whatever the new paradigm brings.
For those who work in corporate America, you may have noticed that many mainframers for example are of the belief that for the last 25 years they have been doing many of the things that SOA suggests. Of course the paradigm itself is not really new only that they have been recently collected into a single work and more importantly branded. There is a difference though in SOA thinking being 25 years old vs. a 25 year old system having thought about it from the beginning.
I wonder when industry analysts and other book authors including myself will ever show that folks who are of the believe that they are doing SOA probably aren't. Likewise, I think the same thing needs to occur in terms of agile software development.
While I have done many agile projects before becoming a full-time employee of a Fortune 100 enterprise, I know have a disease known as hybridism. In consensus-oriented architectures, one must take parts of everyone's ideas and make them work. When this is practiced, is the agile or not! I kinda believe that while I have to label this agile in order to champion a larger goal, in all reality I may be lying to myself. I may be encouraging others to also become delusional.
A very wise architect (name intentionally withheld) several days ago provided me with an analogy on corporate behavior. He stated that architects in corporate America are kinda like a pack of dogs. We wander around looking for stuff to bite. When we find a nice tree, we need to heist our legs and add our unique scent...
Maybe the first thing that needs to occur is for agilists to start working with folks in human resources. The trend towards competencies seems to be growing (Competencies are a trap but this is a topic for another blog) so maybe there is an opportunity to practice hybridism by acknowledging personality styles. Can folks be lumped into one of the following categories:
- Adopted
- Picked up the practice and used it with reasonable correctness.
- Adopted but Distorted
- Picked up on the term and the form but missed the intent and did something not agile.
- Actively Rejected
- Did not adopt the practice and argued against its use.
- Passively Rejected.
- Kept doing things differently form agile practices but never sought to justify or debate.
Would love to hear from other bloggers on whether their enterprises also have similar behaviors and whether they believe hybridism is a mental disorder...
Saturday, February 25, 2006
Outstanding Questions on Federated Identity
I previously asked several questions around Federated Identity and figured I would throw out a couple of additional ones in hopes that someone may know the answer?
| | View blog reactions- I remember in the early 90's there was a wonderful directory service known as StreetTalk that came with Banyan Vines. It seems as if Active Directory now has all the functionality of this particular directory service. Would it make sense for a startup to create Active Directory to run on non MS operating systems?
- xacml is a wonderful spec yet none of the identity bloggers seem to be talking about it. More importantly how XACML should be used in conjunction with SAML, InfoCard, SXIP and YADIS. Would be wonderful to hear your thoughts on it?
- The work of the Liberty Alliance still feels somewhat misguided to me. Only working on specs that software vendors who sell products to the enterprise seems limiting. Do they have any outreach program to folks who don't sell software to large enterprises but yet large enterprises interact with? Salesforce.com comes to mind which seems to not have much interest in directly consuming SAML. Has anyone from Project Liberty ever picked up the phone and talked directly with anyone at Salesforce.com?
- Extending the above question further, shouldn't the folks at the Liberty Alliance be working on specifications that could also be used by consumer applications? Why can't I use SAML to sign onto Yahoo, eBay, Amazon, LinkedIn, google and so on?
- The notion of an Enterprise Service Bus is starting to gain traction in corporate America. Many industry analysts are even recommending to their clients open source ESBs such as ServiceMix which has a larger installed base than many commercial ESB offerings. How should one think about consuming identity within an ESB? If you are of the belief that no one is either doing it and/or doing it incorrectly, what would it take to get a couple of vendors to extend ServiceMix so that it becomes the reference implementation for others to understand this problem-space?
- Many folks in the industry have championed specifications to stop email spam. Isn't the problem really centered around lack of good identity standards? Could SAML and/or XACML result in a better method for stopping spam?
- Current encryption techniques used in both SAML and WS-Federation still rely on components of public-key infrastructure. Have these folks ever heard of Identity Based Encryption? Shouldn't these two things converge?
- I have been having conversations with architects in other Fortune 100 enterprises who also believe that XACML will be huge yet none of the industry analysts have written any detailed research in this area. Anyone have thoughts on how we could get Gartner to produce a magic quadrant and Forrester to do a Wave on all the products that support XACML? I would love to see this emerge by the end of Q1 2006. Of course, I have already suggested it to them but I am a lone voice in the wilderness. Could others also ping them to indicate the importance of this matter?
- The media has jumped all over the GPL 3.0 license and its need for DRM software to include its source. I am of the belief that they are having the wrong conversation and have asked myself several questions in this regard. First, I know that many security algorithms that have stood the test of time were all publicly available. In fact, the notion of security algorithms being open source is at least 120 years old. Instead of recommending closed source approaches to DRM, isn't there a way to accomplish the same goal via open source? Likewise, isn't DRM really also about identity? Why not simply include SAML / WS-Federation hooks into DRM engines and leave the code itself open?
- I ran across a vendor Identity Engines which is putting identity in an appliance form factor. When does this approach make sense and when not?
- Their seems to be two vendors doing something really cool with identity, XACML and other specifications. They are Securent and Jericho Systems. How come no one is blogging about them or the space in which they play? I believe it will be huge. I wonder what it would take to convince Jon Udell of Infoworld to do a bakeoff between these two products in the Infoworld test labs?
Friday, February 24, 2006
Governance by suggestion...
A coworker made an interesting comment in the hallway several days ago regarding the real intent of governance that I thought was worth sharing...
What is the eternal destiny of the enterprise? Does bad governance result in more outsourcing? You don't know but that you may become unemployed any day. Outsourcing and its effect on American jobs is always written from a capitalists eternal perspective doesn't deny your experience.
Although outsourcing and bad governance are predestined does not allow you to take short cuts to whatever the ultimate destiny is. The spirit of good governance requires you must move forward from where you stand.
"Governing" is not equivalent in meaning to "determining". The laws of physics are said to govern the behavior of matter. Does this governance fail or does it determine that diamonds are harder than soap stone? Is this governance by suggestion, like our speed limit signs?
Governance when thought about in an IT context is thought about as financial controls. When thinking in this manner, opportunities to move jobs out of the economy prevails and everyone loses. Of course we can rationalize that outsourcing is good for the economy. But those who truly understand economics, will conclude that rationalization is a trap!
Some folks may think that I am against outsourcing. This is both true and false at the same time. For the record, I am against outsourcing to India but not against outsourcing to say Trinidad. My position is based on economics not suggestions. I know that if $1 leaves the United States more than $1 will come back to the United States for other goods. In Trinidad, they don't make their own cars, many agricultural products and so on as they are directly purchased from the United States. The same thing can't be said of India...
I wonder if IT executives understand that governance is really about changing behavior?
| | View blog reactionsWhat is the eternal destiny of the enterprise? Does bad governance result in more outsourcing? You don't know but that you may become unemployed any day. Outsourcing and its effect on American jobs is always written from a capitalists eternal perspective doesn't deny your experience.
Although outsourcing and bad governance are predestined does not allow you to take short cuts to whatever the ultimate destiny is. The spirit of good governance requires you must move forward from where you stand.
"Governing" is not equivalent in meaning to "determining". The laws of physics are said to govern the behavior of matter. Does this governance fail or does it determine that diamonds are harder than soap stone? Is this governance by suggestion, like our speed limit signs?
Governance when thought about in an IT context is thought about as financial controls. When thinking in this manner, opportunities to move jobs out of the economy prevails and everyone loses. Of course we can rationalize that outsourcing is good for the economy. But those who truly understand economics, will conclude that rationalization is a trap!
Some folks may think that I am against outsourcing. This is both true and false at the same time. For the record, I am against outsourcing to India but not against outsourcing to say Trinidad. My position is based on economics not suggestions. I know that if $1 leaves the United States more than $1 will come back to the United States for other goods. In Trinidad, they don't make their own cars, many agricultural products and so on as they are directly purchased from the United States. The same thing can't be said of India...
I wonder if IT executives understand that governance is really about changing behavior?
Thursday, February 23, 2006
So exactly what is enterprise architecture?
Came across an interesting definition of enterprise architecture that I thought was worthy of amplification...
Meant for Each Other: Enterprise Architecture and SOA. Muli begins with the most pragmatic definition for EA that I have seen in a long while:
He also notes that current EA practices will change from being a "documentation, procedures and guidelines" body and will reposition itself as a practical, implementation-oriented discipline aimed at the creation of an Enterprise Management Infrastructure, while SOA will be repositioned, no longer as an Integration/Interoperability architecture, but rather as an Enterprise Management architecture. In my humble opinion, using SOA strictly for integration is evil...
| | View blog reactionsMeant for Each Other: Enterprise Architecture and SOA. Muli begins with the most pragmatic definition for EA that I have seen in a long while:
Enterprise Architecture is an infrastructure and a set of Machines constructed in order to manage a chaotic, dynamic, unpredictable, complex, organic, prone to error, frustrating, Enterprise IT, which has to support an ever increasing, dynamic portfolio of products and services, through constant "ASAP, Now, Right-Away" modifications of business processes.
He also notes that current EA practices will change from being a "documentation, procedures and guidelines" body and will reposition itself as a practical, implementation-oriented discipline aimed at the creation of an Enterprise Management Infrastructure, while SOA will be repositioned, no longer as an Integration/Interoperability architecture, but rather as an Enterprise Management architecture. In my humble opinion, using SOA strictly for integration is evil...
Wednesday, February 22, 2006
Outstanding questions on becoming an industry analyst
Recently, several bloggers have talked about becoming an analyst, getting it right and being paid for it!. Of course I have lots of unanswered questions...
Figured I would limit my question to just five things:
| | View blog reactionsFigured I would limit my question to just five things:
- One of my five most favorite analysts, Stephen O'Grady of Redmonk mentioned here that many analysts from other firms were interested in working for Redmonk which is cool, but he wouldn't be interested in paying them more than he makes. For folks who have never been an industry analyst, what is the typical compensation model out there?
- James Governor also of Redmonk wrote a wonderful blog entry on How to become an industry analyst. The hard part is knowing what steps one should take to get their first client? For example, if I hang my hat out as an analyst and I want Oracle to be my first client, do I pick up the phone and call Mr. Ellison?
- Some folks have "hinted" that smaller analyst firms while on the rise may be struggling in terms of cashflow. Is this a tactic to discredit the competition or is this backed by research?
- Some small analyst firms hold industry conferences while others don't. Many folks in corporate America love trips to resort locations and sometimes use analyst research as a justification for vacation. Should these small firms continue to deny folks that practice this?
- I have seen many bloggers comment on how software vendors should interact with industry analysts but have never seen anyone really explain how us folks in corporate America should? Come someone please blog about best practices in this space?
The fallacy of integrity within the industry analyst community
Joe Guralnick in his blogged asked an interesting question: what if we knew the products that run many industry analyst's internal systems? Should they be bound to publish what vendor products they use? Would it be intriguing to know if the internal IT folks actually consume their own research?
When many enterprise architects make decisions around new technologies for their enterprises, they may start with research reports. Some will use it as input while others will use it as a filter and not consider vendors other than the ones listed as leaders. The latter are evil.
The one subliminal product endorsement that pretty much all the large analyst firms give is towards Blackberry. You ever notice how many of them use it at conferences? Will have to pay attention to see what brand of laptops the big guys use.
The one emerging trend that I wish they would talk alot more about is the savage practice of inventorying within corporate America. This is just another bad practice that has become pervasive and is a side effect of IT aligning with the business instead of providing guidance and leadership.
Imagine if you were an enterprise architect for Wild Oats (My favorite supermarket) and the CIO wanted to know how much storage is used by relational databases. Would you then run out and count every database for every application?
Now imagine the business wants to know how many cans of soup are on the shelves. Instead of walking the aisles, taking inventory of everything on the shelves, and then storing that inventory data in a database, while establishing periodic reconsiliation practices, instead just leave the "data" with the can of soup. Then, in the business process of restocking, the nightly, hourly or however frequently scan of all the RFID tags in the store bypasses the step of storing the inventory data in a database and goes directly to placing an order for more of that can of soup. Not only does the resulting business process come closer to achieving real time timing, but a step is eliminated from the process.
Note that in the above scenario, you would have eschewed creating a "framework", you would have avoided six sigma like analysis paralysis and instead chose innovation as the driving factor. Do you think that in this situation, innovation could have also reduced otherwise growing storage costs?
Inventorying nor any other form of metrics gathering can never provide real alignment. Maybe alignment comes by adoption of innovation as a mindset vs. publishing historical reports to aid in the justification of otherwise questionable decisions. Maybe enterprise architects at our competitors should ignore this message and instead keep filtering, inventorying and putting things into nice boxes...
| | View blog reactionsWhen many enterprise architects make decisions around new technologies for their enterprises, they may start with research reports. Some will use it as input while others will use it as a filter and not consider vendors other than the ones listed as leaders. The latter are evil.
The one subliminal product endorsement that pretty much all the large analyst firms give is towards Blackberry. You ever notice how many of them use it at conferences? Will have to pay attention to see what brand of laptops the big guys use.
The one emerging trend that I wish they would talk alot more about is the savage practice of inventorying within corporate America. This is just another bad practice that has become pervasive and is a side effect of IT aligning with the business instead of providing guidance and leadership.
Imagine if you were an enterprise architect for Wild Oats (My favorite supermarket) and the CIO wanted to know how much storage is used by relational databases. Would you then run out and count every database for every application?
Now imagine the business wants to know how many cans of soup are on the shelves. Instead of walking the aisles, taking inventory of everything on the shelves, and then storing that inventory data in a database, while establishing periodic reconsiliation practices, instead just leave the "data" with the can of soup. Then, in the business process of restocking, the nightly, hourly or however frequently scan of all the RFID tags in the store bypasses the step of storing the inventory data in a database and goes directly to placing an order for more of that can of soup. Not only does the resulting business process come closer to achieving real time timing, but a step is eliminated from the process.
Note that in the above scenario, you would have eschewed creating a "framework", you would have avoided six sigma like analysis paralysis and instead chose innovation as the driving factor. Do you think that in this situation, innovation could have also reduced otherwise growing storage costs?
Inventorying nor any other form of metrics gathering can never provide real alignment. Maybe alignment comes by adoption of innovation as a mindset vs. publishing historical reports to aid in the justification of otherwise questionable decisions. Maybe enterprise architects at our competitors should ignore this message and instead keep filtering, inventorying and putting things into nice boxes...
Tuesday, February 21, 2006
EA and Reference Architectures...
My peer asked here for me to provide a definition of reference architectures. Figured I should respond...
An architecture can exist at many levels. Minimally, at the conceptual and physical levels with lots of stuff in between these two perspectives. The key belief is that architecture in of itself is not really physical. Architecture is an abstract concept (sometimes the folks responsible for creating it are more abstract that the architecture itself but that is a topic for another blog) that encompasses many categories of principles. Architecture is the art, science, method, and style of building something that fulfills the practical and expressive requirements of a group of humans.
Individuals or groups create architectures to fulfill their specifications. Users, who set the goals, establish different types of architecture, not the architects. Architectures tend to be stable, and to change an architecture, a need must exist that exceeds economic considerations (see past blogs on software engineering economics), because repetition is less expensive than experiment (always true) and innovation (mostly true).
In an architecture, standardization of elements can be useful to achieve financial saving or, more importantly, an architectural value. A good architecture creates an attractive appearance and connotes the intended message to the beholder. The thing being built using a good architecture should not only be structurally stable but should also appear to be stable (An architecture minimally shouldn't smell).
The thing that the enterprise needs is the notion of a reference architecture that is known and developed to the extent that one enterprise can find a way to use another enterprise's architecture, for whatever reason. This begs the question of whether each and every single enterprise should create their own or should figure out how to borrow from others. Reinvention of points of reference across enterprise boundaries may serve the need to achieve buy-in but fails on economics, use of best practices and adherence to accepted forms of body of knowledge.
Reuse of reference whether accomplished by standards, by clever software design, or both, is something that must be investigated and discussed. The things we have with which to work are the enterprises, that are comprised of people, then processes then tools in that order should come with frameworks; enterprise models; suggested or required methodologies; and guidelines and rules for using each. The enterprise architecture, or enterprise-reference architecture, is the organization of all of these things.
Should reference architecture guide the following?
Anyway, I would love to hear from others on their interpretation of reference architecture.
| | View blog reactionsAn architecture can exist at many levels. Minimally, at the conceptual and physical levels with lots of stuff in between these two perspectives. The key belief is that architecture in of itself is not really physical. Architecture is an abstract concept (sometimes the folks responsible for creating it are more abstract that the architecture itself but that is a topic for another blog) that encompasses many categories of principles. Architecture is the art, science, method, and style of building something that fulfills the practical and expressive requirements of a group of humans.
Individuals or groups create architectures to fulfill their specifications. Users, who set the goals, establish different types of architecture, not the architects. Architectures tend to be stable, and to change an architecture, a need must exist that exceeds economic considerations (see past blogs on software engineering economics), because repetition is less expensive than experiment (always true) and innovation (mostly true).
In an architecture, standardization of elements can be useful to achieve financial saving or, more importantly, an architectural value. A good architecture creates an attractive appearance and connotes the intended message to the beholder. The thing being built using a good architecture should not only be structurally stable but should also appear to be stable (An architecture minimally shouldn't smell).
The thing that the enterprise needs is the notion of a reference architecture that is known and developed to the extent that one enterprise can find a way to use another enterprise's architecture, for whatever reason. This begs the question of whether each and every single enterprise should create their own or should figure out how to borrow from others. Reinvention of points of reference across enterprise boundaries may serve the need to achieve buy-in but fails on economics, use of best practices and adherence to accepted forms of body of knowledge.
Reuse of reference whether accomplished by standards, by clever software design, or both, is something that must be investigated and discussed. The things we have with which to work are the enterprises, that are comprised of people, then processes then tools in that order should come with frameworks; enterprise models; suggested or required methodologies; and guidelines and rules for using each. The enterprise architecture, or enterprise-reference architecture, is the organization of all of these things.
Should reference architecture guide the following?
- Whether to outsource or maintain competitive advantage in-house
- Whether to build reference architectures internally or buy them
- Hiring practices that allow the enterprise to get the best in the industry and not just rationalize mediocrity
- Whether to embrace open source for competitive advantage and not just commoditization and cost considerations
- Steer IT executives towards notions of strong technical leadership
- Adoption of agile methods for software development
- Whether an enterprise should interact with a larger community in terms of blogging and speaking at conferences
- Modern approaches to architecture including declarative programming, event-driven architectures and Bayesian Belief Networks
- Whether to spend lots of money on commercial portal software or adopt an open source portal such as Liferay
- Whether to spend lots of money on commercial Enterprise Service Bus or adopt an open source ESB such as ServiceMix
Anyway, I would love to hear from others on their interpretation of reference architecture.
The Lies told by the Open Source Community
Many within the open source community are into Microsoft bashing while others who advocate open source are really telling lies. Maybe its time for industry analysts to start pointing out who exemplifies true open source ideals vs. those who are simply twisting it in order to deceive folks within the enterprise...
"Open Source" has started to lose some of its idealistive values. These values are best summed up by the Open Source Definition's ( OSD ) 10 Commandments:
1. Free Redistribution
2. Source Code
3. Derived Works
4. Integrity of The Author's Source Code
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavor
7. Distribution of License
8. License Must Not Be Specific to a Product
9. License Must Not Restrict Other Software
10. License Must Be Technology-Neutral
If you take the time to review the OSD, you will soon realize that many of the so-called industry leaders in the Open Source movement are actually violating the values upon which it was founded. In many cases these are monopolistic corporations who are simply using Open Source as a marketing tool to increase their profits. Companies who use “hybrid” business models which involve selling closed source applications that run on top of open source code (Several database companies come to mind) or companies who release an open source "loss leader" application with hopes to upsell these users into their commercial offering (Several multi-billion dollar software companies come to mind). The funny thing is that Microsoft is probably the only large software company that hasn't resorted to this unethical practice.
This paradigm has been well covered in many industry publications in recent months but none of them have dug deep enough into why this practice will be detrimental to large enterprises who buy into open source for cost savings reasons and not the real reason they should such as interacting with a larger community, getting better quality or improving time to market.
Even many analyst firms themselves have embraced research into the open source space but few have actually figured out ways to incorporate it into their own business model. Should we trust their advice when they are equally guilty?
| | View blog reactions"Open Source" has started to lose some of its idealistive values. These values are best summed up by the Open Source Definition's ( OSD ) 10 Commandments:
1. Free Redistribution
2. Source Code
3. Derived Works
4. Integrity of The Author's Source Code
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavor
7. Distribution of License
8. License Must Not Be Specific to a Product
9. License Must Not Restrict Other Software
10. License Must Be Technology-Neutral
If you take the time to review the OSD, you will soon realize that many of the so-called industry leaders in the Open Source movement are actually violating the values upon which it was founded. In many cases these are monopolistic corporations who are simply using Open Source as a marketing tool to increase their profits. Companies who use “hybrid” business models which involve selling closed source applications that run on top of open source code (Several database companies come to mind) or companies who release an open source "loss leader" application with hopes to upsell these users into their commercial offering (Several multi-billion dollar software companies come to mind). The funny thing is that Microsoft is probably the only large software company that hasn't resorted to this unethical practice.
This paradigm has been well covered in many industry publications in recent months but none of them have dug deep enough into why this practice will be detrimental to large enterprises who buy into open source for cost savings reasons and not the real reason they should such as interacting with a larger community, getting better quality or improving time to market.
Even many analyst firms themselves have embraced research into the open source space but few have actually figured out ways to incorporate it into their own business model. Should we trust their advice when they are equally guilty?
Monday, February 20, 2006
Interesting Debate between two book authors (Scott Ambler and Charles Betz)
Scott Ambler and Charles Betz are expressing diametrically opposed visions to governance. Figured that the blogosphere could jump in and provide their own two cents...
Curious what the blogosphere thinks?
| | View blog reactionsCharles Betz originally started the debate here. Scott Ambler finished it. The essence of the debate is continued below...
>
> Scott - I now regret mentioning you on my weblog. But since you
have
> chosen to respond instead of just letting it pass, I guess we have
have
> let this play out. Hopefully I won't lose too many subscribers.
I'm not
> going to let this thread continue beyond a few posts.
Charles, you'll only lose subscribers if they feel that you're
wasting their time.
When you attack someone publicly, you shouldn't be surprised when
they respond. One of your existing subscribers was concerned that
you had chosen to attack me, and was kind enough to let me know that
it had happened.
>
> 1. I read your whole article. I stand by my quote. It was fair. I
> wasn't reviewing your whole site. I don't agree that a weblog
author
> needs to inform the subjects of their postings.
It's common courtesy to do so.
>
> 2. You didn't mention ITIL in that specific article. You made a
blanket,
> misleading statement to your audience in that article, including
people
> unfamiliar with your other work, who might well take that
statement at
> bald face value - "there's nothing out there, folks!" The longer
version
> you provided below is equally misleading.
Charles, you chose, in your arrogant manner, to imply that I needed
to read about ITIL. Had you chosen to do your homework, perhaps
something as simple as Googling my name with those terms, you would
have very quickly discovered that I have gone out of my way to
promote ITIL. If you have egg on your face now, it's clearly not my
fault.
As others have pointed out to you, COBIT is not very well accepted
within the community. ITIL, in my opinion, is much better accepted
although still struggles to become mainstream.
>
> There IS a large body of work and knowledge on IT governance,
extending
> even beyond ITIL, COBIT, and CMM. We just don't have the
controlling
> professional organization to rationalize and "accept" it like the
> accountants do (although ISO 20000 is a start). And no framework
ever
> claims to be one size fits all - they all need context-specific
> interpretation and tailoring.
Agreed. And it's doubtful we'll ever have such an organization
within our lifetimes and it's even more doubtful that it will come
from the command and control crowd.
>
> 3. Popularity has nothing to do with using COBIT vs. Agile. That's
a
> ludicrous apples and oranges comparison. COBIT is not incompatible
with
> Agile, and ITIL is equally capable of generating paper pushing.
Popularity is important. If COBIT isn't on people's radar scopes,
then it is very likely not a viable option for most development
shops. Considering that COBIT has been around for a long time, I
wouldn't hold out much hope for it.
>
> 4. The heart of the matter: You still have to answer for your
advocacy
> that project teams can/should bypass IT governance ("blocking") if
it
> suits them. Do you disavow this unethical article:
>
http://www.sdmagazine.com/documents/s=8269/sdm0307h/sdm0703h.html ?
Thank you for misrepresenting me once again, although I appreciate
that you at least shared the URL with people. In that article, I
clearly state that blocking should be considered a last option only
when the bureaucrats around you prove to be too inflexible to work
with you effectively. To quote, from the middle of the article:
"First, you need to find a way to work with these folks. An agile
team should have stakeholders from all involved areas, so everyone
involved will need to be flexible—including you. You must listen to
their concerns and questions, and find ways to gain their trust and
interest in the project. They must be willing to try working in an
agile manner—which means an evolutionary approach. "
The folks that it refers to were described in the previous
paragraph, data administration, quality assurance and enterprise
architecture groups (that isn't meant to be an extensive list).
Later in the article, I advise: "So what do you do if other people
aren't flexible enough to evolve their approach into a more agile
one—even after you've tried education and communication? The answer
is simple—you block them. "
At the end, to quote again:
" Remember, if you're using a blocker or intend to do so, your
organization clearly has a big problem. Though blocking can serve as
an effective stopgap measure to get a project past the goal line, in
the larger sense, it's like applying a Band-Aid to an injury that
requires major surgery. Subterfuge should be a last resort, but if
you've failed all other attempts (education and communication
foremost among them) to combine an agile team with a rigid power
structure, blocking may be your only alternative to maintain the
agility necessary to reach your goal. Use a blocker if you need to
get through the project, but after that, step back, evaluate the
situation and consider rethinking your approach to software
development. "
So, where is the ethics problem? I very clearly identify a common
problem, suggest that people try to do the right thing and work with
these other groups constructively, but only as a last resort block
them in order to get the job done. The mission of software
development teams is to build high-quality working software which
meets the changing needs of the project stakeholders. If they're
being prevented from doing so by these other groups of people, then
they need to find a way to get the job done. The real ethical
problem is why are these dyfunctional enterprise groups even being
tolerated, because in my experience if one team is blocking them
then more than likely many teams are.
Futhermore, in the article I also point out that blocking appears to
be quite a common practice. To quote: "Lately, I've been talking
about blockers at conferences. When I ask people if they're doing it
now or if they've done it in the past, I see a lot of hands held
high. When I ask if they've been caught, only a few hands remain
aloft. The coin flips both ways, too: If you're not working directly
on a project team, but instead are "supporting" one or more teams,
you may want to ask yourself whether you're being blocked. "
What's your real issue Charles, afraid you're being blocked but
can't tell if it's happening? Or worse yet, are you being blocked,
know it, but can't do anything about it?
>
> Until you formally retract this, in print, we will continue to have
> major differences - and I will continue to view you as a person
with
> little standing to discuss questions of IT governance (my basic
> motivation for criticizing your article). Previous discussion,
never
> resolved:
>
> http://groups.yahoo.com/group/dm-discuss/message/8830
> http://groups.yahoo.com/group/dm-discuss/message/8853
> http://groups.yahoo.com/group/dm-discuss/message/8856
> http://groups.yahoo.com/group/dm-discuss/message/8858
> http://groups.yahoo.com/group/dm-discuss/message/8860
>
Charles, bottom line is that I appear to have fairly decent standing
within the practical subset of the IT community.
I'll let others be the judge on this list. What do you think about
my February column, or about the need for blocking once all other
avenues have failed project teams which are trying to get the job
done?
>
> 5. IT professionals deal with "useless bureaucrats" every day in IT
> finance, HR, quality assurance, PMO, and yes, data admin. Get a
broader
> perspective on what the control process is trying to achieve and
apply
> process improvement techniques to wring out all true non-value-add
> activities - don't just trash the people who have the misfortune
to be
> the enforcers.
I have a spectacularly broad perspective on software process. I
(co)-wrote the first CMM-Level 5 compliant process for OO
development (the two Process Patterns books), the first major
extension to the RUP (the EUP book and earlier the UP series from
CMP books), in addition to several books on agile techniques.
I've had the opportunity to work in a wide range of organizations,
and I've seen the results of a wide range of techniques.
Frankly, if you think that your role is to "enforce" a process then
you've already lost the battle.
>
> 5. I have never misrepresented anything you have said or wrote.
You just
> go out on a limb sometimes and make irresponsible statements, and
you're
> too influential to not get called on it.
Please. You clearly misrepresented me in your initial post.
Don't assume that you can attack me and not get called on it.
- Scott
Curious what the blogosphere thinks?
Enterprise Architecture and resume driven design
Scott Mark, an architect for a Fortune 200 enterprise recently blogged: Resume Points to Consider if you want a job at a large enterprise. I have always wondered how prevalent is resume-driven design amongst enterprise architects in choosing a technology based on what will pad out your resume?
In thinking about it, it is more prevalent than IT executives would expect. Architects who will only consider software products that are on quadrants at the expense of valuable working software that can be cheaply obtained from the open source community may be guilty of this practice. In cultures where outsourcing is prevalent, this may become practiced even more making the sole architect who dissents stand out like a sore thumb.
Likewise, outsourcing firms have the same problem in that many of their staff are "freshers" who understand the importance of building their resumes. IT executives in America fall into the trap by allowing them to have a say in the architecture as they are of the belief that buy-in increases the chance for success.
I would love to know if there is a such thing as an empowered enterprise architect in Fortune 100 enterprises that can go against the rallying forces of resume-driven design and change direction with minimal effort. Imagine if someone could simply say: "The reason I want to choose product X is because I want to learn it..." it would at least make some sense to me. I wouldn't even get in the way if it were stated in this manner as they are being truthful and coming up with a useful goal. I guess governance as typically practiced fails in this regard because it requires folks to be less than honest...
In thinking more about governance, this behavior in some situations should be encouraged. Language and technology choices affect management's ability to keep the people they have and attract new people. More importantly, it helps counter the disease known as Rationalization.
A strong governance process should acknowledge that languages, processes and products are chosen for social reasons and otherwise may not be justified for technical or even business requirement reasons. If you are looking to hire top talent and tell a candidate that you wrote your system in Smalltalk or even COBOL, they may think, "If I take this job, it's a dead-end career move for me." If an enterprise archtiect is justifying technology choices based on the idea that the enterprise going to have to hire a replacement or make the need to outsource diminish, that's fine. You've not made the choice technically. You've made it socially, and that's OK. This is good governance and should be stated as such as long as it is publicly acknowledged...
| | View blog reactionsIn thinking about it, it is more prevalent than IT executives would expect. Architects who will only consider software products that are on quadrants at the expense of valuable working software that can be cheaply obtained from the open source community may be guilty of this practice. In cultures where outsourcing is prevalent, this may become practiced even more making the sole architect who dissents stand out like a sore thumb.
Likewise, outsourcing firms have the same problem in that many of their staff are "freshers" who understand the importance of building their resumes. IT executives in America fall into the trap by allowing them to have a say in the architecture as they are of the belief that buy-in increases the chance for success.
I would love to know if there is a such thing as an empowered enterprise architect in Fortune 100 enterprises that can go against the rallying forces of resume-driven design and change direction with minimal effort. Imagine if someone could simply say: "The reason I want to choose product X is because I want to learn it..." it would at least make some sense to me. I wouldn't even get in the way if it were stated in this manner as they are being truthful and coming up with a useful goal. I guess governance as typically practiced fails in this regard because it requires folks to be less than honest...
In thinking more about governance, this behavior in some situations should be encouraged. Language and technology choices affect management's ability to keep the people they have and attract new people. More importantly, it helps counter the disease known as Rationalization.
A strong governance process should acknowledge that languages, processes and products are chosen for social reasons and otherwise may not be justified for technical or even business requirement reasons. If you are looking to hire top talent and tell a candidate that you wrote your system in Smalltalk or even COBOL, they may think, "If I take this job, it's a dead-end career move for me." If an enterprise archtiect is justifying technology choices based on the idea that the enterprise going to have to hire a replacement or make the need to outsource diminish, that's fine. You've not made the choice technically. You've made it socially, and that's OK. This is good governance and should be stated as such as long as it is publicly acknowledged...
Sunday, February 19, 2006
Successful Enterprise Architecture
Been noodling what it means to be successful and whether I view myself that way. My definition of success is: To work with people whom you like and respect, in a role that plays to your natural strengths, in an area that you are genuinely interested in...
A common question about leadership is whether leaders are born or bred. My experience leads me to conclude that leadership can, in fact, be learned. Of course, certain folk who are born with the natural charisma gene of which I wasn't. My mentor always tells me to find someone who can become your bearingpoint.
During our last conversation, my mentor and I discussed how Jack Welsh is a great leader. He was of the belief that Jack was only successful because the culture allowed him to be and it wouldn't be possible to emulate Jack within our company. In fact, he predicted it would result in failure.
I would love to hear from other enterprise architects that have figured out the secret sauce to success within their own enterprise. For me, maybe my real problem is that I am not interested in climbing the corporate ladder. In all reality, I want the corporate elevator. If I can't have that then I tend not to bother. Maybe I will have to get in line and wait my turn...
| | View blog reactionsA common question about leadership is whether leaders are born or bred. My experience leads me to conclude that leadership can, in fact, be learned. Of course, certain folk who are born with the natural charisma gene of which I wasn't. My mentor always tells me to find someone who can become your bearingpoint.
During our last conversation, my mentor and I discussed how Jack Welsh is a great leader. He was of the belief that Jack was only successful because the culture allowed him to be and it wouldn't be possible to emulate Jack within our company. In fact, he predicted it would result in failure.
I would love to hear from other enterprise architects that have figured out the secret sauce to success within their own enterprise. For me, maybe my real problem is that I am not interested in climbing the corporate ladder. In all reality, I want the corporate elevator. If I can't have that then I tend not to bother. Maybe I will have to get in line and wait my turn...
Plaigarism in India
Noted co-author Yakov Fain just got his website content stolen by some folks in India. See this article.
Glad to see the media talking about this issue...
| | View blog reactionsGlad to see the media talking about this issue...
Saturday, February 18, 2006
How to improve industry conferences
Been thinking about conversations several of my peers have had regarding attendance at industry conferences and figured I would share them...
Here are several thoughts:
| | View blog reactionsHere are several thoughts:
- Conference chairs, thinly veiled sales presentations chock-a-block with eye candy by industry CTOs and consultants are starting to bore folks. It really isn't that difficult to get speakers from corporate America or even government. The main problem may be the model where you sit back and wait for folks to propose ideas to you instead of being proactive and tracking them down.
- The hotel rates are obscene. I know part of the package you folks pay for a venue includes the notion of selling a block of hotel rooms but seriously, you need to get the prices down a lot cheaper. For example, if a conference is held in New York City in Times Square, why would I pay the conference discounted rate of say $199 when I can simply jump on priceline and find a cheaper hotel next door.
- Your conference really should have a bookseller. Booksellers shouldn't be thought of as vendors, so don't try to sell them space. Give it away freely. Invite publishers and acquisitions editors to your event. Folks appreciate the ability to buy books on a subject that they may have heard discussed. You are further helping them with their goal of learning and they will repay you by talking to others about their experiences.
- Help others network. The one thing that I really appreciate at conference is in talking with peers of other Fortune 100 enterprises. If I can't see their company name clearly on their name tag then it makes this goal more difficult. Likewise, how about figuring out a way that we could make arrangements based on who will be attending in advance?
- The best conferences are not just about the sessions during the day but tend to also figure out events for after-hours. A person may have never been to that particular location and would love to see things. They could of course always pickup brochures in the hotel lobby but would appreciate advice so to avoid tourist traps. Help them have a good time not only during the conference but after.
- The demographics of IT has changed dramatically from the time I first started in IT to today. Make sure the menu has a diversity of food choices. Don't choose items such as ham sandwiches or other pork products. Make sure that you have vegetarian items, kosher and halal items. If this need cannot be practically met due to cost considerations, at least attempt to figure out in advance, local restaurants that may serve this need.
Friday, February 17, 2006
So exactly what is thought leadership?
The name of my blog has the notion of thought leadership within its title. On several occasions, I have provided definition for it in the past but figured I would revisit it...
Masood Mortazavi in his blog provided an interesting take on thought leadership:
Likewise he also provided a definition of dialog leadership:
I tend to focus more on the former since I am of the belief that this is more lacking in society as far as the content of my own blog is concerned. Does blogging in of itself allow one to also start a dialog so that I am in all reality in both courts?
| | View blog reactionsMasood Mortazavi in his blog provided an interesting take on thought leadership:
"Thought leadership" is about leading through a mostly solitary activity that has been had. We have had some thoughts, at best involving a small clique of people, and then we go out and try to "lead" with those thoughts.
Likewise he also provided a definition of dialog leadership:
"Dialog leadership" is about creating opportunities to think together creatively and to learn from each other.
I tend to focus more on the former since I am of the belief that this is more lacking in society as far as the content of my own blog is concerned. Does blogging in of itself allow one to also start a dialog so that I am in all reality in both courts?
Humorous Thoughts on Cheney and Clinton
Was noodling the similarities between democratics and republicans and realized that there isn't much difference between them...
Heard interesting commentary on the radio today. Cheney and Clinton have the following things in common:
| | View blog reactionsHeard interesting commentary on the radio today. Cheney and Clinton have the following things in common:
- Both have avoided the media after the scandal on their crimes were discovered
- Both seemed to have managed to not do any time nor even get arrested for things the rest of us would have
- And at the end of the day, both of their victims got sprayed...
Thursday, February 16, 2006
Thoughts on Agile IT Executives
The Agile Manifesto seems to resonate with those who have strong technical backgrounds but hasn't yet crossed the chasm into non-technical IT management. The primary reason is that many agile practices focus on the role of the developer which runs contrary to current thinking of outsourcing, IT governance and PMP certification. They don't have to be opposed forces though...
Management (distinct from leadership) may not understand the characteristics of agile practices and will feel threatened, or may not understand how to “lead” their team in this manner. It has the potential for a power struggle between management and those who deliver valuable working software on a daily basis. I guess bottom-up works in some cases but not all.
Folks in other enterprises have made a drastic mistake in asking their management to promote agile software development from the top down. Executives are recognizing agile benefits and want to leverage agile techniques to make their company more customer focused, responsive to customers and improve their customer relationships. However, just as bottom-up methods have the potential of threatening the leaders, a top-down approach has even a greater likelihood of creating a negative reaction among the developers. Anything that attempts to push responsibility, accountability, visibility, exposure and risk to them may cause them to push back.
So, if bottom up isn't cool and top-down approaches cause the same result then what is the right answer? The answer is of course governance. Governance should affect behavior and not just be a financial / process control. Agility is enabled when executives represent and support the principles of agility but should stop short of actually recommending the creation of agile processes. Likewise, they need to internalize that people, then process, then tools in that order also enable agility.
Hopefully some of them will read this posting on Agile Enterprise Architecture...
| | View blog reactionsManagement (distinct from leadership) may not understand the characteristics of agile practices and will feel threatened, or may not understand how to “lead” their team in this manner. It has the potential for a power struggle between management and those who deliver valuable working software on a daily basis. I guess bottom-up works in some cases but not all.
Folks in other enterprises have made a drastic mistake in asking their management to promote agile software development from the top down. Executives are recognizing agile benefits and want to leverage agile techniques to make their company more customer focused, responsive to customers and improve their customer relationships. However, just as bottom-up methods have the potential of threatening the leaders, a top-down approach has even a greater likelihood of creating a negative reaction among the developers. Anything that attempts to push responsibility, accountability, visibility, exposure and risk to them may cause them to push back.
So, if bottom up isn't cool and top-down approaches cause the same result then what is the right answer? The answer is of course governance. Governance should affect behavior and not just be a financial / process control. Agility is enabled when executives represent and support the principles of agility but should stop short of actually recommending the creation of agile processes. Likewise, they need to internalize that people, then process, then tools in that order also enable agility.
Hopefully some of them will read this posting on Agile Enterprise Architecture...
Wednesday, February 15, 2006
Outstanding Questions on OpenSolaris
Been busy reading the blogs of many folks from Sun searching for answers to outstanding questions. Figured I would ping them in hopes that they may address many of my questions in upcoming blog entries...
| | View blog reactions- It is now popular for a software vendor to offer an appliance version of their product. It seems as if most appliances run Intel chips. Any reason why they aren't using Sparc chips?
- Does Sun help software companies build price-competitive appliances built on the Sparc chip or does one have to look elsewhere?
- I am aware of companies such as MBX Systems that make appliances but can't seem to find any industry analyst information on the appliance building space. Who is king of the hill?
- Any software companies out there that make an appliance form factor running Solaris on Intel?
- If they also wanted to run Open Solaris on this appliance, what documents should they read so that they can strip the operating system down to bare minimum functionality?
- Is anyone working on getting Open Solaris to join an Active Directory Domain? I know that there are several third-party products in this space but curious when it will be native?
- Are there any coding "best practices" to take advantage of Solaris containers?
- Does Xen currently working with Open Solaris?
- Can Open Solaris support headless and diskless operation?
- Are there legal implications in using Open Solaris in either appliance or embedded designs?
- Is there merit in doing a port of Open Solaris to the Z/390 platform?
Enterprise Architecture, Agile Software Development and the PMO
Several architects within our enterprise have been meeting on a weekly basis over lunch brainstorming our next set of recommendations to move our thinking forward. While we have had great successes in agile software development, we haven't done much in terms of agile project management. There are several things that the lunch crew has landed on that are worthy of further discussion...
Agile approaches encourage iterative planning. Most folks when adopting an iterative approach tend to think in terms of short iterations from the perspective of timeboxes but miss a more important subtle thought that says iterations become focused on features and not tasks.
Project planning on the features that customers believe are important keeps the project team and the customers synchronized (because the customers understand the product even though they may not understand the technical activities). It also
focuses the team on delivering the product vs keeping track of task-oriented details that many enterprises love to waste time on...
Another aspect isn't frequently discussed is that in many shops, business analysts and the folks from QA desire to participate in all technical discussions. Some developers feel that they will slow down the development process if they allow these folks to participate. Reality states that balance is achieved if the QA folks participate on technical discussions and decisions made by developers as they have the responsibility for automating acceptance testing.
Don't forget the forming/storming/norming/performing principle.Although your team struggles more then most, they have to get through the storming phase, and they can only do that on their own. What you could do is find exercises to facilitate the discussions between your two stormers. Sometimes it is better to stand back and let the events take their course...
The main problem though is that in many shops, the notion of letting events take their course becomes siderailed by agendas of program/project management offices and therefore it becomes vital that they too become aware of what agile approaches offer them.Agile development looks like just iterative development to a command-and-control-style management culture. In this style, it is the PMO management who must collect the metrics from below and decides whether any project has reached the point of diminishing returns.
The main problem that enterprise architects ned to start championing is the whole reward system. Of course, if they start with rewards for themselves, it will appear selfish. The key to masterin selfishness is the ability to get what one desires without others detecting this goal. One way would be to champion additional rewards for project managers which will immediately get them on your side.
If project managers were rewarded for understanding their own project well enough to make this decision themselves (or more realistically suggest it to the PMO), then some agility would indeed be percolating up to the management level. In most organizations, a project manager who decided his/her own project had outlived its usefulness would be making a really stupid career move.
Enterprise architecture must deal with people issues in order to be successful. Likewise, it should also have a Bill of Responsibilities along with an Elevator Pitch that is understandable by PMO type folk. Likewise, it is vital that enterprise architecture doesn't take actions that create more Urban Legends.
In the meantime, I figured I would sweeten the deal on a previous post entitled: Where's the WSDL by also adding a $100 contribution to a mutually agreed upon charity to the first person who solves this puzzle...
| | View blog reactionsAgile approaches encourage iterative planning. Most folks when adopting an iterative approach tend to think in terms of short iterations from the perspective of timeboxes but miss a more important subtle thought that says iterations become focused on features and not tasks.
Project planning on the features that customers believe are important keeps the project team and the customers synchronized (because the customers understand the product even though they may not understand the technical activities). It also
focuses the team on delivering the product vs keeping track of task-oriented details that many enterprises love to waste time on...
Another aspect isn't frequently discussed is that in many shops, business analysts and the folks from QA desire to participate in all technical discussions. Some developers feel that they will slow down the development process if they allow these folks to participate. Reality states that balance is achieved if the QA folks participate on technical discussions and decisions made by developers as they have the responsibility for automating acceptance testing.
Don't forget the forming/storming/norming/performing principle.Although your team struggles more then most, they have to get through the storming phase, and they can only do that on their own. What you could do is find exercises to facilitate the discussions between your two stormers. Sometimes it is better to stand back and let the events take their course...
The main problem though is that in many shops, the notion of letting events take their course becomes siderailed by agendas of program/project management offices and therefore it becomes vital that they too become aware of what agile approaches offer them.Agile development looks like just iterative development to a command-and-control-style management culture. In this style, it is the PMO management who must collect the metrics from below and decides whether any project has reached the point of diminishing returns.
The main problem that enterprise architects ned to start championing is the whole reward system. Of course, if they start with rewards for themselves, it will appear selfish. The key to masterin selfishness is the ability to get what one desires without others detecting this goal. One way would be to champion additional rewards for project managers which will immediately get them on your side.
If project managers were rewarded for understanding their own project well enough to make this decision themselves (or more realistically suggest it to the PMO), then some agility would indeed be percolating up to the management level. In most organizations, a project manager who decided his/her own project had outlived its usefulness would be making a really stupid career move.
Enterprise architecture must deal with people issues in order to be successful. Likewise, it should also have a Bill of Responsibilities along with an Elevator Pitch that is understandable by PMO type folk. Likewise, it is vital that enterprise architecture doesn't take actions that create more Urban Legends.
In the meantime, I figured I would sweeten the deal on a previous post entitled: Where's the WSDL by also adding a $100 contribution to a mutually agreed upon charity to the first person who solves this puzzle...
