Agile Elephant

Enterprise Architect Careers

I've been wondering what the correlation is between the economy being in freefall and the sudden need for Enterprise Architects.  All of a sudden I am getting calls from many clients looking to hire new and also backfill EA openings.

I have to be honest and tell you that consulting and staffing budgets for 2009 are looking dismal (although I think this would be a time where we would want to let technology help drive business...but that's for another post).  But all of a sudden I am encountering a strong need for individuals who are true EAs.  The current climate allows some of my clients to be a little more selective, where in the past they would have looked beyond the fact that a candidate was missing one particular skillset.

But the fact remains that EAs are being hired and also selected for consulting roles.  Perhaps the correlation is the fact that many companies do 'get it'.  That technology advances can create cost savings and drive revenues.

I would be missing a unique opportunity if I didn't post one hot opening that I am currently working on.

This particular client is one of the leading data management (ETL) software companies in the marketplace today.  They are well known as having the leading package for managing data in large (multi-terabyte) high-throughput environments.

The are seeking Enterprise Architects who are hands on technical and have a strong application development/systems engineering background.

Experience in either the Financial Services or Government industries is key.  These EAs must have worked in high transaction-type environments (i.e. trading systems).

They are most certainly NOT seeking Architects who are more interested in navigating the office politics that often go along with a senior architecture role.  They are seeking individuals who can function in a hands-on capacity and also perform in a client-facing role.

Some travel is involved as this is a consulting role but, based on your particular geographic location, that could be very limited.  Compensation packages are generous and negotiable.

Contact me if interested in discussing this or any other Architect roles.  System One is leading the way for building the only dedicated Architecture consulting and staffing firm in the U.S.  Get on board!

Spotting Resume Fraud

A good article in the WSJ on how to spot resume fraud.  Times are obviously tough and people are getting desperate.  The subtleties of the candidates' career and academic history can be easily overstated and, in some instances, flagrantly falsified.  The article points out some very key points:

• Confirm the circumstances of every change in employment
• Ask the candidate for exact dates of prior employment and have him/her explain gaps
• Don't rely solely on the references provided by the candidate
• Don't assume that candidates provided by an Executive Search firm have been fully vetted
• Run a web search

In the realm of Technology Architecture, there are many other areas that are ripe for fraudulent claims.  Let's put aside for the moment thathe title "Enterprise Architect" has been seriously diluted by many individuals claiming to be what they are not.  But we should all be aware of areas that can be verified as it relates to Architecture:

• Check credentials such as TOGAF and LZA status
• Speak directly with individuals that most recently worked with the candidate.  As a rule of thumb, I like to speak with someone who worked with the candidate, someone who worked for the candidate and someone whom the candidate reported to.  These are essential.
• Last, but certainly not least in my book, is gut instinct.  For those of us who have been interviewing candidates for longer than we can remember, there is a gut feeling that you get as to whether or not the individual will fit within your organization.  Follow that instinct and act accordingly.

The glut of candidates in the marketplace does not diminish the need to hire the best and brightest available.  Our jobs are only made that much harder in separating the wheat from the chaffe.

 

Interview with Todd Biske

I recently had the opportunity to interview Todd Biske, Senior Enterprise Architect for Monsanto and fellow blogger, regarding SOA Governance and his new book which was recently published regarding the same topic.

Congratulations on the new book Todd. With all the different SOA topics discussed in the blogosphere and elsewhere over the past few years, why did you choose to write about Governance?

To be completely honest, it started when the publisher contacted me and suggested that topic. I had contemplated writing a book before, but knew that it was a pretty heavy time investment and technology books tend to have a short shelf life. After I was contacted, I was very surprised to find that someone hadn't written a book about SOA governance. I also knew that SOA governance isn't about technology, it's about people, policies, and processes. As a result, a book on it could have a much longer shelf life than a book on Web Services or BPEL. The clincher was when a colleague at Monsanto told me that he had looked for a book on SOA governance and would have bought one if it was available.

What do you see as one of the biggest problems companies are facing when structuring their governance procedures?

One of the biggest problems is inadequate goal setting. Simply saying you want to adopt SOA is not enough. This particular scenario happens in Chapter 3 of my book. Why are you adopting SOA and what are measurables results you want to achieve? Without doing this first step, you are at risk of creating fiefdoms of power that are inconsistent across the organization because each "governor" let alone the "governed" may have their own definition of what adopting SOA. Even if you have stated policies, are those policies connected back to a stated goal? If not, how do you justify following the policies when people invariably resist the change?

How can a company find the best balance between “not enough” and “too much”?

I don't buy the whole not enough/too much argument. Every company has governance, it's more a question of how visible (and painful) it is. Adherence to policy needs to be easy and desirable. The key is to focus on your goals and education early and often so you don't find yourself in such a state where a heavy handed approach is the only way to make change happen in the desired timeframe.

Who in the company should be involved on the governance team? Should it just be architects or should developers or even users be involved as well.
It depends on the things that need to change, but in general, I would expect it to be a very broad set of roles. The book includes various architects, IT management, analysts, platform managers, and even representation outside of IT. If you need policies around how projects get defined and funded to ensure that the "right" services get built, it is certainly possible that business strategists, managers, and architects may be involved and those roles may come from outside of IT. Project-time or design-time governance policies may come from the senior technical staff within IT, while run-time governance may involve more of the IT operations staff.

You know that my blog, Agile Elephant, is focused on the human capital aspects of IT. So I have to ask how much and what aspects of the Governance process should be automated and what aspects need personal oversight?

Automation of auditing/enforcement is always good, and wherever possible, it should be used. Tools won't define the process, however, so you must have people in place to determine the best way to leverage the technology. There are many policies that are still difficult to codify, so people will still have a big role. My preference is that they focus on education first, though. Give people the knowledge and hopefully self-policing will handle the majority of things.

The book is called SOA Governance. Who is this book geared toward in the organization?
Senior leadership in IT: architects, managers, and technical leads. I don't consider it a technology book.

So, do you mind saving me a few bucks and telling me the Key to Successful SOA Adoption now?

Buy my book! Seriously, it is about effective governance. Define your goals and your desired behavior, then have your best people develop the policies and processes that will result in those goals and behavior. That is what governance is all about.

How can someone pick up a copy of the book?

It is available from the publisher at http://www.packtpub.com/soa-governance/book, as well as Amazon and other online bookstores.

Thanks for your time Todd! Best of luck with your book.

Thanks!

Agile Thoughts For the Day

You Say EA, I Say SOA: Let's Call The Whole Thing Off:  Joe McKendrick points out that these two terms may be converging.  Until the skills gap is closed, however, and more Enterprise Architects better understand SOA, then it will be hard to use these terms interchangably.

Grown Men Can Cry: The human aspects of technology and the efforts we all put forth for others are really what makes everything worthwhile.  Maybe our personal/charitable interests should be higher up on the resume for employers to see...But would they care?  I think Jim McGovern would.

Go Big Blue!: Now I'm a Dallas Cowboy fan trapped in NY Giant country, but how lucky is this guy.... You know, I think that's actually Mike Kavis.

My Favorite Posts

I guess I could be considered a 'newbie' to blogging as I just started a year ago, but I've learned a great deal and also met some very interesting people during this journey.  Going back and looking at my posts for the past year was a good experience for me.  I wanted to give you some of my favorites.

Happy New Year to all and I wish a properous 2008 to each of you!

• Consultants are Going Fast!
• Enterprise Architects: Needles in a Haystack?
• SOA and Going Green
• SOA Governance: Is There Such a Thing as Too Much?
• It's a Mad, Mad, Mad, Mad Recruiting World
• Are You an Enterprise Architect...
• Enterprise Architects as Impact Players
• Winning the War for Top Talent: Build a Talent Factory
• Put Your Talent on Display
• Enterprise Architects and Online Poker
• Do Women Hate IT?  Should We Care?
• Keep Your Job From Being 'Bangalored'
• Becoming a Recruitable Enterprise Architect

Enterprise Architects, Governance and Humility

I would suggest to you that one of the most important traits to value in your enterprise architect or architecture team is humility.  In speaking with a number of EAs and C-Level professionals, I can summize that many are fearful to accept the advice of others and/or admit to their own weaknesses in managing their responsibilities.

By way of some background, my conversations with these professionals centered on the need for a sound governance policy as it relates to SOA.  As I just recently read in SOA World: 

Governance is the tail that wags the SOA dog.  An organization that deploys Web Services without a solid governance program is headed for serious trouble in terms of reliability, security and cost.

Due to the nature of the work and the reverance of the title, many Enterprise Architects are overly confident in their ability to manage and lead certain efforts (such as building a governance policy).  They are hesitant to accept the advice and input of others.  As an Executive Search professional, I'm very leary of anyone I speak with that claims to 'know it all'.  I find that a little bit of humility goes a long way to establishing yourself as a true leader.

Why are we often so afraid to say "I don't know"?  And why would ignorance be a negative trait?  I find that the best job candidates that I deal with are constantly striving to learn more about their profession and don't just put themselves on a pedastal as the guru to architecture.

The Company EA is on Line Two

James McGovern is fielding recruiting calls again.  I think I'll need to give him a call as I'm starting to feel left out.

The most recent inquiry involved an Enterprise Architect position primarily based on telecommuting.  I had recently blogged about these types of opportunities and I am still of the opinion that the role of the Enterprise Architect is one that requires a regular on-site presence to remain effective.

So I too would like to hear from other Enterprise Architects that work in a full remote model.  If this is an effective methodology, how do you make it so?

Agile Thoughts For The Day

SOAH or Ess-Oh-Ay: OK, maybe we have 'jumped the shark' in the SOA blogosphere....

Oracle Tenders Offer to BEA:  Speaking of sharks....

SOA Beyond the Hype:  I'm a fan of Todd Biske and always appreciate his ability to take complicated topics and explain them clearly.

Gender-Based Recruiting for EAs:  Bravo to Cisco for its marketing push.  Call me if you need help!

SOA Governance - The Carrot and the Stick:  The human element to governance is critical.  We want to automate as much as possible, but there needs to be some personal involvement...Right?

Becoming a Recruitable Enterprise Architect

My apologies for being away from the blogging realm for a brief period.  The Executive Search business is picking up a big head of steam on multiple fronts and it has simply consumed most of my time.  But I'm back on track and look forward to sharing insights and ideas on recruiting.

James McGovern has posted a few items of late regarding Enterprise Architecture and how this particular profession is managed by recruiters and executive search professionals.  He has also taken me to task personally to define 'talent' as a need within an organization.

I believe that I am unique in the sense that I am an Executive Search professional that dedicates his time to identifying and placing Enterprise Architects; especially those that have a strong understanding of SOA principles.  James (I hope I'm not being too forward using first names) claims that he is typically the first one contacted for EA positions due to his high accessibility on the internet (blogs, LinkedIn, etc.).  Well he is certainly correct that one's ability to be found on the internet creates a higher probability of being contacted by a company or a recruiter.  I highly recommend to everyone that is interested in exploring the career marketplace that they do everything they can to increase their presence utilizing the same methods that James does...blogging, LinkedIn (posting your profile as well as asking/answering questions).  Blog Roll links are also very helpful for increased exposure (any help here James?).

But what James should be very careful of are those recruiters that are simply contacting him because the two words "Enterprise Architect" happen to be in his title.  I personally have never contacted James for a job opportunity even though I am currently working on multiple needs for this type of candidate.  My lack of contacting him is driven by two factors:  First of all, and most importantly, his employer is a client of mine and I will not ravage the company that I work to build.  This is a professional ethic that I hope most recruiters follow.  Secondly, I simply have not had a position that fit James' profile.  Now I don't profess to know his background backward and forward, but I know enough from his internet presence to understand his general profile.  This second point, however, is rather moot due to my previously mentioned client relationship.

But the overall point I am attempting to make is that those recruiters or companies that are contacting him based on his title are more lost than they will ever know.

I understand his point regarding competitive compensation:

"The phrase, competitive compensation tends to mean mediocrity where they don't pay below the line, nor will you be highly compensated but will simply end up in the middle of the pack"

This is an overused term by recruiters and probably deserves some better clarification.  Recruiters are often hesitant to post an exact dollar figure in their recruiting efforts for fear of scaring away potential candidates with either too high or too low of a dollar figure.  Hopefully better information is being given to the candidates upon their initial conversation with the recruiter, but I must admit that I am as guilty of this practice as anyone.  I will endeavor to revise the policy of my staff (myself included) in at least posting more definitive information regarding salary, bonuses and other monetary and non-monetary perks.

Part of the conversation vs. interview dilemma is a tough hurdle to overcome.   As you'll read in his post, James had a great 'conversation' with an SVP that attempted to directly recruit him.  In this case, James was a known entity to this SVP due to the efforts that James had gone through to make himself visible on the net and through other mediums.  But when the client or recruiter is exploring the unknown, then many times the need for more of an 'interview' approach is necessary at first to gain some perspective.  All interviews will go much more smoothly if approached in a more conversational tone.  Would you want to work for a firm that just peppered you with questions for 2 hours?  I think not.

Recruiting is truly an art that we should all strive to perfect.  This is most important with clients that are looking to hire top talent.

While the Webster dictionary has two main definitions for the word, they both seem to work well:

1. The natural endowments of a person.

2. A unit of value equal to the value of a talent of gold or silver.

Any way you slice it, talent is a measure of value.  For our purposes, it is the value that one brings (or can bring) to an organization.  The organizations that understand the importance of this value are the ones that will succeed.  Too many companies are focused on their short-term goals (project-based needs) and are not paying any attention to hiring individuals (or existing employees) that can grow in their company.  Building a talent factory is a difficult process and cannot be done merely by attempting to match candidates with key words on a job description.  I'm sure James is smart enough to understand the difference when he is contacted.

VDA and its Relevance to Enterprise Architecture

by Jonathan Kahn

In Zapthink’s recent article about avoiding Vendor Driven Architectures, David Linthicum makes the case that choosing one vendor for your enterprise’s SOA needs is perilous and potentially costly. While this caution bell rings soundly, it appears that today most enterprises may have little choice but to turn to their chosen vendors. Once this process has been started by an inquiry, there is a tendency to march down a very rigid, pre-defined sales process in a winner-take-all battle of wit, determination and even (dare I mention it) discount-wielding (usually in the form of multi-product bundle discounts and ‘free’ support). Sound familiar, oh yeah, I bet it does.

But, having played on both sides of the “death by committee” and ever-evolving requirements matrix game (aka the loathed ‘RFI process’), I’d say most everyone is aware that vendor and product selections are often based on data that comes from other [in hindsight via ROI lenses] successful deployments. The vendors are all too eager to toss you customer references like tradeshow trinkets to help you build executive confidence. Meanwhile, it all comes down to trust and ability to deliver in the end - even if it takes a few extra release cycles to complete the full reference architecture, right?

In the early days of SOA [technology] adoption, as it's always been, favorable outcomes with trusted partners (in this case the big infrastructure vendors) are just about all that a good architect could turn to in solving our favorite, if recycled issue of IT Governance. (And in so doing, a whole slew of causal issues, related to the pace of change in the general business climate, affecting that of the release-cycle crazed software industry, become prevalent)

All the various pressures to produce with a fast-food style delivery, the architecture blueprints that would ordinarily take patience, devotion and painstaking process to distill into meaning, forces us down a deterministic path of Product Platform Selection or (worse still,) Presumed Business Requirements. Increased urgency to IT alignment and buzzwords like “agility” in the business climate only serve to accelerate the decomposition of even the most seasoned IT Architect’s resolve and diminish the most confident practitioner’s integrity in the unbiased practice of their art. Adding to the challenge are the growing list of skills, certifications and aptitudes that some of the recent Executive Architect-seeking clients we’ve been working on, seem to consider as pre-requisites.

And so, it seems to me that one of the industry’s favorite paradoxes is really at work here. What I am referring to is the incontrovertible fact that growing seasoned architects is challenging; it does not happen in a vacuum, but rather via repeated exposure to the meatiest projects of the enterprise, with an occasional diet of vendors’ approaches to applications infrastructure delivery and management. Though the recipe may come in several versions, high-caliber Enterprise Architects are born and differentiated more by life experience, than by pattern analysis and creative problem solving, though these are very important skills they ultimately need to hone.

And so it follows that as a direct result of their homogeneous rearing, a smaller group of architects are out there with a balanced range of experiences to draw upon, especially when it comes to competency in the bottom two layers of the SOA reference architecture – ‘process’ and ‘service’. Still fewer, I would argue, have the requisite tenure of experience that leads to comfort and facility to finesse (or goad, as it were) a board-room full of business stakeholders toward a viable service delivery model, no matter how many Governance tomes they’ve recently consumed.

And so what tends to happen? We invariably gravitate to the hallowed ground of urban legend: IT Standards - in this case seeking synergy at the business semantics layer, which, while it's evolving makes it hard to have meaningful discussions with our business counterparts. Usually, even the most well intentioned, unanimously accepted and methodologically sound business decomposition effort meets some resistance; and the more complexity involved, the greater the likelihood of a stalled initiative.

The bottom line is that there is no substitute for practical diligence and credibility, which flows like confidence from real-world experience. When combined with business requirements in the proper measures, IT Strategy and Governance can actually lead to SOA nirvana. And even better news is that skilled practitioners do exist, and not only in the womb of large, costlier concerns like the IGS, Accentures and Deloitte’s of the world.... Nay, I’ll be the first to attest that if you’re open to a meeting and a seeker of synergy, you might even rub shoulders with one of these professionals at your next Architecture conference. And so here’s my tip for spotting them: They’ll stand out in a crowd easily as consensus builders (not so much as pundits) because the same traits that make them great architects, usually render them approachable and willing to seek challenges, offering their help to others. In my short tenure in the field, I’ve already met several who seem to really "get it" - who have what it takes to build consensus and promote alignment toward common goals, and I find this pretty encouraging for the rest of us who are still learning these skills.

So, not to shamelessly pitch our own service, we’ve been busy populating and categorizing the profiles into the Architect Resource Center (ARC) to help you find them as easily as possible.