gdp's Comments

Midwest IT Survival : Cloud Computing is Evolutionary not Revolutionary

Fri, 17 Jun 2011 13:39:31 +0000

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!

Midwest IT Survival : On-line Banking Security on Trial Again

Fri, 17 Jun 2011 13:30:35 +0000

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 (http://en.wikipedia.org/wiki/Jon_Fisher) and Thomas Varghese (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.)

Midwest IT Survival : Conflict between Agile and Architecture

Mon, 16 May 2011 11:01:09 +0000

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.

Midwest IT Survival : Conflict between Agile and Architecture

Wed, 11 May 2011 13:25:55 +0000

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

Midwest IT Survival : Conflict between Agile and Architecture

Wed, 11 May 2011 13:23:54 +0000

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.

Midwest IT Survival : Organizational Structure and Enterprise Architecture

Wed, 11 May 2011 01:46:42 +0000

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.

Midwest IT Survival : Single View of the Work, Summary

Fri, 22 Apr 2011 13:58:15 +0000

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!

Midwest IT Survival : Single View of the Work, Part 12

Fri, 8 Apr 2011 17:36:10 +0000

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.

Midwest IT Survival : Single View of the Work, Part 11

Fri, 1 Apr 2011 17:09:39 +0000

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.

Midwest IT Survival : Single View of the Work, Part 9

Thu, 17 Mar 2011 23:27:07 +0000

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.

Midwest IT Survival : Single View of the Work, Part 6

Wed, 23 Feb 2011 12:04:29 +0000

Mark, Thanks for your feedback on this series of posts. I've had number 7 in the series in draft mode for some time. I just need to put some time into proofing it and getting it posted. Your comment has motivated me to get this pending article off the sidelines and into the blog. Look for it soon. John

Midwest IT Survival : Instant IT Gratification

Fri, 28 Jan 2011 12:02:42 +0000

Thanks for your feedback Peter. When collecting my thoughts in this post I didn't consider ordering my recommendations. I would most certainly agree, asking the "whys" first is a much stronger partnering effort than throwing out arbitrary charge back constraints on new work requests from the business. I wholeheartedly agree that the middle manager in this post needs to continue to bring the spot light back to the root cause. The struggle I see is what should the middle manager do while the senior leadership is moving towards but hasn't reached a more mature IT and business alignment? My recommendations were for that "stuck" middle manager that is pulling his or her proverbial hair out while waiting for that improved alignment to manifest itself. It is very refreshing to hear you link the IT governance issues to being CIO-level problems. For IT engineers and middle managers in the trenches it can be very exasperating to continue to come up with low level work arounds for such systemic company cultural challenges such as a lack of support for a stronger level of IT governance.

Midwest IT Survival : Instant IT Gratification

Thu, 27 Jan 2011 12:17:26 +0000

Absolutely! Governance is lacking in an organization where the business is directing rather than partnering with IT. I tried to relate possible techniques for managers that are "stuck in the middle" and can't just walk into the CIO's office an say "implement some governance by Friday so this problem goes away". Sure, the root cause lack of governance will still be there and take a culture change championed by the CIO and other IT members with business relationship management in their job function to begin to correct. Yet, as a manager in the middle, you aren't completely stuck. You have some techniques to leverage to try and make the best of a challenging situation. Thanks for sharing your thoughts @dwwright99

Midwest IT Survival : How did you get started in programming

Thu, 13 Jan 2011 13:32:23 +0000

Ah, the joys of having low level control over your computing environment. With today's layers upon layers of modular coding practices and borderline configuration rather than coding IDEs, I wonder if the next generation of programmers will even grasp the peek and poke techniques of the past. Thanks for commenting!

Midwest IT Survival : Project Work Estimation as Art

Tue, 4 Jan 2011 01:49:44 +0000

As I re-read the lines you pointed out, I realize the sarcasm I was intending wasn't coming through as clearly as I originally thought. I'll have to add a correction/clarification to indicate the lack of a magic methodology that completely eliminates, as you say, the unstoppable human tendency to remember a date, no matter the context that date was shared. Thanks for taking the time to stop by and share your perspective and especially catching my unintended implication that one methodology solves all communication challenges.

Midwest IT Survival : Project Work Estimation as Art

Thu, 9 Dec 2010 13:47:35 +0000

Absolutely spot on, but what I find so fascinating about the IT and business project discussions is how easily participants fall into this trap. I find it takes very strong professional discipline to keep one's desire to help the business succeed with restraining agreement on small changes without vetting the total "cost" of adding the change. I pride myself on having an ear for requirements discussions to preempt commitments on changes until vetting has occurred, but I still fail at times to keep my business value delivery focus in check. Great comment, thanks for stopping by and sharing it.

Midwest IT Survival : Project Work Estimation as Art

Thu, 9 Dec 2010 11:44:39 +0000

@CIOesTV, Thanks for stopping by and offering your comment. Yes, your point about technical folks being auditory is indeed true. Verbally sharing information, such as in a meeting, creates the risk that participants may want away with a different version of the "truth". A technical resource may say "I think I can get that done by the end of the month" where as a business person hears that statement but interprets it as "I will get what I need from IT by the end of the month thus I will begin to plan accordingly". At the end of the month, when the technical person shares "I only got about half the work done because of X, Y and Z" the business person is surprise and confused because they didn't interpret the possible failure to get the work done by the end of the month. At this point, let the management escalations fly! Sharing work breakdowns in writing and with as many visual elements as possible goes a long way towards clarity of message and early dialog on "what if" planning to achieve a viable delivery plan with associated contingencies.

Midwest IT Survival : Project Work Estimation as Art

Wed, 1 Dec 2010 17:29:03 +0000

Thanks for the feedback Scott ... in order to let "everyone know the consequences of the constant shifting priorities", as a manager, you have to build up all the data to then be able to show to requesters/sponsors the effect of the shift ... with data. You can't just "if you want this, then that will slip." It has to be more data driven: "If you want this, this is going to take 34 hours which if started today, would mean your would get this on MM/DD/YY. In order to work on this, that is going to have to be paused which means we originally said that would be delivered on MM/DD/YYY and thus would now be delivered on MM/DD/YY instead. Is that ok?" It takes time and energy to get to the ability to have this prioritization conversation. It also takes a total team commitment. You can't have one person supporting the data and another person promising crazy delivery dates. A consistent external message is critical for this to work.

Midwest IT Survival : Gartner IAM – Day 3

Thu, 18 Nov 2010 14:35:46 +0000

Interestingly there wasn't anyone talking about biometrics to any serious degree. It was mostly IT software and service providers that sponsored the conference, thus lots of people selling SSO and provisioning software tools. One vendor whose names escapes me at the moment was providing keyboard typing dynamics software. Their pitch was the timing of how different people press keyboard keys in order to type in a word/phrase/sentence is different enough to be used for stronger identification. Since it is biometrics-lite and doesn't require a specific/unique hardware device ... everyone has a keyboard. I know one of the challenges is if the physical keyboard layout changes. One might type particularly fast on their primary keyboard but if you were borrowing a keyboard with different key spacing or tactile feel, your typing would be different. Thus, they claim to combine device profiling and typing patterns. Complex to install in an existing application, but it provides additional "context" which seems to be the theme of online authentication these days.

Midwest IT Survival : Gartner IAM – Day 1

Wed, 17 Nov 2010 16:03:07 +0000

Scott, thanks for stopping by and sharing your thoughts. Would I be poking the proverbial bear if I mentioned a national ID?