Scott, thanks for stopping by ...

Don't let the vendors and technology consulting companies hear you diminish the hype that is building around the cloud. There is lots of money to be made in riding the marketing/buzz wave. :-)

Seriously and less flippant, it seems the pendulum of centralized versus decentralized computing is continuously at play. The mainframe brought stability, change and cost management, ability to scale along with inflexibility, innovative constraint and prioritized functionality (compared to instant gratification). Distributed servers meant flexibility, ability to locally versus globally prioritize functionality, and local scaling along with a lack of change and cost containment among other things. Thus "the cloud" does appear to represent the most sophisticated attempt to merge the benefits of each extreme while attempting to minimize the negatives.

Not sure if my response helped provide some clarity or further proverbially muddied in the water.

In either case, again, thanks for stopping by!

Jim,

You bring up a great points in your comment. I should have been more articulate in my closing comments about a potential influx of new technology aimed at trying to position a product that balances stronger security with minimal impact to the on-line customer experience (if such an appraoch exists). Being a veteran of the last round of FFIEC on-line guidance issuance in 2005 from the financial services (FI) in-house security side, the FI product teams were struggling with just how much change/impact to the on-line experience would customers tolerate. The perception that security is the inverse of convenience was prevalent. The bank that implemented something as significant as out-of-band transaction authentication/authorization where previously not implemented was concerned uneducated/unappreciative customers would revolt and take their banking business to a perceived more “convenient” bank. Plus, the sheer marketing hype and security punditry at the time that fraud was rampant and banks were doomed unless they implemented some crazy, half baked new security “thang” didn't help. Much repressed in-house security staff jumped on the hype bandwagon for it gave them a seat at the table rather than being pushed to the background. Add in traditional bank IT/security budgeting cycles suggesting an unfunded mandate competing with product road maps and in-flight multi-year product project investments and the pragmatic need for real security enhancement got muted with all this noise.

Thus, the device based authentication trend codified by PassMark and Bank of America seemed to be the safe play for FIs, the middle ground for executive decision making. Device based authentication suggested: meet the letter of the guidance, minimize the customer experience impact, increase the security toolbox in case this on-line fraud stuff accelerates and contain unfunded mandate expenditure all in one approach. I am not saying this was massively strategic thinking on the part of FIs, but given all the noise and emotion surrounding the 2005 FFIEC guidance, it seemed the risk adverse play for banks (given ACH fraud was mired in Reg Z, who has to pay for fraud losses which is still being settled in the courts).

I had the opportunity to work directly with security technology copies at the time, such as the Arcot and PassMark technical folk but more so with the Bharosa team of sharp folks assembled by Jon Fisher <a href="http://(http://en.wikipedia.org/wiki/Jon_Fisher)" target="_blank">(http://en.wikipedia.org/wiki/Jon_Fisher) and Thomas Varghese <a href="http://(http://twitter.com/#!/twitwithtom)" target="_blank">(http://twitter.com/#!/twitwithtom) that provided new security technologies involving rules/risk engines and device based forensics with built in integration for out-of-band auth/az services (such as Authentify's offerings). Hopefully the organizations that were more strategic and invested in these more comprehensive security products will be able to leverage that investment and finally extend into the full transaction out-of-band security space.

So maybe one of the current challenges is: Does today's on-line consumer appreciate the security value of out-of-band transactional auth/az and look for it as a market differentiator in bank product selection/use rather than resist it as onerous/intrusive?

Jim, thanks for stopping by and taking the time to share your thoughts.

(DISCLAIMER: IF my current employer has a relationship with Authentify I am unaware and I am not actively pursuing a relationship with Authentify on behalf of my employer.)

Eric, thanks for taking the time to stop by and share your story. Sounds like you were able to avoid the stress of converting a highly customized site into a structured site constrained by Sharepoint. I can image the conversations surrounding the conversion team "... but in the old site we could just do X. Sorry, in Sharepoint you can't do X you have to do W, then Y, then Z then finally X." Repeat as many times as their were customizations in the old site.

BTW ... thanks again for stopping by and sharing your thoughts!

Scott, you indeed bring up a valid point for the "build vs. buy" debate. Given a magic wand I would wave it and ensure that the "build versus buy" challenge would always land on the side of "build". In this article, my brain immediately applied the filter of the current state of the financial services industry. With banks crawling out of TARP and the recent financial services melt down having cut delivery teams to the bone in order to "keep the lights on", in my mind, a typical bank IT department is still hesitant to re-hire large in-house development teams to start building out new online products. Thus, I applied this filter without really explaining myself.

In the short term, the CMS buy or Portal product buy or whatever the current term for "web framework that has customize-able pre-developed widgets and workflow to support content creation/migration/approval" is probably the best play for bank IT management without the green light to re-ramp up staff. I also assumed for this exercise that a bank with such an antiquated online banking product (which bank has a read-only online banking product today?) was very likely to have exceedingly low IT funding and thus doesn't posses a highly skilled, nimble in-house development staff.

Hmmm, if the goal of the exercise was to focus on the technology exclusive of the management aspects I have probably disappointed. In my tenure in IT I've always found the potential technology solutions to be far ahead of the management/people/cultural issues.

Jason,

First, thanks for stopping by and sharing your thoughts. I probably wasn't clear in that I wasn't proposing that a decentralized model made EA impossible. Rather, I was alluding to the challenges facing EA when there isn't a central EA function. Even if the architects are on loan from a central EA group to each decentralized line of business supporting IT silo, it takes strong EA leadership to enforce common architectural standards and practices. It is very easy for an architect to get caught up in the deadlines and challenges of the silo-ed IT group in it's quest to deliver services to it's respective line of business.

Again, not an impossible situation that can't be over come by a strong EA function. Thanks for the feedback. I'll keep digging into organizational influences on enterprise architecture and keep your comments in mind.

Scott, thanks for your extremely positive feedback. I've been kicking around the idea of compiling some of my posts into a book ... stay tuned!

Scott, thanks for the feedback. Indeed, "emergency requests", if acted upon immediately can thrash a team to the point no work actually gets "done". Rather, incremental tasks get completed but technical debt sky-rockets and yesterday's delayed emergency request uncompleted catches up and creates client dissatisfaction. A client or customer might want to have everything done right now but the feasibility just isn't there. Without the data to support that claim, clients and customers may draw the wrong conclusion and think you and your team isn't effective in doing the job.

Mark P, thanks for the positive feedback. I encourage you to share how you are finding this series helpful in relation to your management or team leadership role.

Scott and Mark P.,

Thanks for the positive feedback. I've had success with this approach at three separate companies in three separate industries. Thus, I feel confident in sharing what I've found to work for me when it comes to leading technical teams in companies where IT doesn't produce the product for sale. Rather, IT enables the business to provide goods and services more efficiently.

I'm revising a few more posts in this series, thus look forward to additional articles that flush out this approach to technical team management.