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 reactions


 

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 reactions


Monday, February 27, 2006

 

Open Source Routers

The notion of open source routers are long overdue...


| | 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 reactions


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 reactions


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


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 reactions


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:
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...


| | View blog reactions


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 reactions


 

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 reactions


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?
I have my own beliefs on the above questions and think reference architecture should address some but not all. I will state for the record though that I would love to see vendors within a demographic along with the industry analysts that cover them to start creating more. I especially desire this of the business rules community to unify and work together on this problem space.

Anyway, I would love to hear from others on their interpretation of reference architecture.


| | View blog reactions


 

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


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...

Charles 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?

| | View blog reactions


 

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 reactions


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 reactions


 

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 reactions


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 reactions


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:
"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?



| | View blog reactions


 

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 reactions


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 reactions


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


 

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 reactions


This page is powered by Blogger. Isn't yours?