NorthTemple@SXSW
Some of the members of the Church's interaction design team will be at the South by Southwest conference (SXSW) again this year. They're having a get together. If you'll be there, go by and say hello.
Tech Talk in Bay Area?
Several of our directors will be in the bay area April 22 - April 26. We are considering a tech talk there if there is enough interest.
The tentative agenda would be:
Please respond to this post if a) you’d be interested in attending a tech talk in the bay area or b) if you have a suggested venue. We’ve had these on site at a vendor location in the past and that has worked quite well.
[Deleted my comment asking people not to post requests for tech talks in other locations as it sounded a little snooty. Thanks to the reader who pointed that out.]
Thanks!
The tentative agenda would be:
- Keynote (joel)
- Infrastructure breakout (dave)
- Development breakout (david)
- Interaction Design breakout (tadd)
- Community breakout (tom)
- Building to building video breakout (pete)
Please respond to this post if a) you’d be interested in attending a tech talk in the bay area or b) if you have a suggested venue. We’ve had these on site at a vendor location in the past and that has worked quite well.
[Deleted my comment asking people not to post requests for tech talks in other locations as it sounded a little snooty. Thanks to the reader who pointed that out.]
Thanks!
Customization
My background is in software development so my first inclination in solving a business problem is to turn to custom software. I have to fight that urge as off-the-shelf applications are often more cost effective than custom-developed ones.
Commercial off-the-shelf (COTS) applications are wonderful if they match your business process. Many of these applications incorporate process models which are based on industry best practices and thus if you can match your business processes to industry practices, you can benefit from an industry's collective wisdom. Plus you have many more users testing "your" code for you. Your company may use a small percentage of the available features of a given solution, but the economies of scale a vendor leverages in creating a COTS application make a 10% value proposition worth the full investment in the product.
Note I said "if they match your business processes." If they do not then you have two choices. You can change your business process to match the tool (much easier said than done) or you can customize the tool.
Customization. Traditionally, when we've needed to make a change to a COTS application, we've customized the tool. It's so easy to do! You don't have to worry about buying new equipment, testing new configs, installing new baselines, testing in staging, etc, etc, etc. You just do some simple "configuration" (read: write code) and publish the changes out to production in the tool that's already been pushed there. It's typically that easy.
But is it worth it?
Firstly, you can rarely build what you'd REALLY like to build with the simple customization tools available in a COTS application. If you can live with vanilla then the simplicity in using these configuration tools can be worth it in the short-term.
So what happens when you upgrade? That's when you feel it in your pocket book. We've been riding the upgrade train of our ERP system for years. We've made many, many customizations. They're necessary customizations, but they make our upgrade to new versions of our software very painful. At some point you start to wonder if it wouldn't have been smarter to write the software yourself instead of purchasing an expensive COTS application. I'm coming to the conclusion that the answer is no for many COTS applications.
Here's the credo we're developing at the Church wrt COTS applications.
This approach isn't always a popular one:
But we think it's the best one for us.
Commercial off-the-shelf (COTS) applications are wonderful if they match your business process. Many of these applications incorporate process models which are based on industry best practices and thus if you can match your business processes to industry practices, you can benefit from an industry's collective wisdom. Plus you have many more users testing "your" code for you. Your company may use a small percentage of the available features of a given solution, but the economies of scale a vendor leverages in creating a COTS application make a 10% value proposition worth the full investment in the product.
Note I said "if they match your business processes." If they do not then you have two choices. You can change your business process to match the tool (much easier said than done) or you can customize the tool.
Customization. Traditionally, when we've needed to make a change to a COTS application, we've customized the tool. It's so easy to do! You don't have to worry about buying new equipment, testing new configs, installing new baselines, testing in staging, etc, etc, etc. You just do some simple "configuration" (read: write code) and publish the changes out to production in the tool that's already been pushed there. It's typically that easy.
But is it worth it?
Firstly, you can rarely build what you'd REALLY like to build with the simple customization tools available in a COTS application. If you can live with vanilla then the simplicity in using these configuration tools can be worth it in the short-term.
So what happens when you upgrade? That's when you feel it in your pocket book. We've been riding the upgrade train of our ERP system for years. We've made many, many customizations. They're necessary customizations, but they make our upgrade to new versions of our software very painful. At some point you start to wonder if it wouldn't have been smarter to write the software yourself instead of purchasing an expensive COTS application. I'm coming to the conclusion that the answer is no for many COTS applications.
Here's the credo we're developing at the Church wrt COTS applications.
- Buy over build when possible, but only if we're willing or able to bend our business process to match the tool we would be purchasing. When customizing, abstract code from the COTS application (and especially the DB tables) when extensions are necessary.
- We look carefully at the number and severity of customizations we'll have to build and if we determine that they will pass a certain threshold, we decide to build.
This approach isn't always a popular one:
"We've already got an ERP system! Let's use it!"
"The vendor promises a smooth upgrade path!"
"The tools are soooo simple!"
But we think it's the best one for us.
LDS.ORG
We apologize for the slowness of lds.org the last two weekends. We've recently moved to a new infrastructure and haven't yet figured out the right configuration for caching and garbage collection.
If there are any Websphere/Vignette experts out there, make yourself known in the LDS.ORG forum over at our tech web site!
Thanks for your patience.
If there are any Websphere/Vignette experts out there, make yourself known in the LDS.ORG forum over at our tech web site!
Thanks for your patience.
7: Make It Easy
We communicate clearly, avoid complexity in our solutions and improve & follow processes so that it is easy to work with ICS.
What an industry we work in! How many emails did you send 15 years ago? How many web pages did you surf? For most of us the answer is zero. Can you now imagine a world without computer technology? So much has changed in such a small amount of time.
All of you techies will probably understand 100% of the following conversation.
Matilda: Whatcha doin?
Orpheous: Surfing the web.
Matilda: Did you know Google uses AJAX?
Orpheous: Yup, but they also use a lot of C.
Matilda: Man, they must be using a serious DBMS.
Orpheous: Yeah, I have a friend who writes SQL for them.
Matilda: They don't use ADO do they?
Orpheous: Yeah right. And their servers run on DOS.
Matilda: LOL.
Matilda: I just got a new mobile device!
Orpheous: A blackberry or a palm?
Matilda: Pocket PC. And it supports both GSM and CDMA!
Orpheous: Cool. Does it support WAP?
Matila: Oh yes! And straight TCP/IP!
Orpheous: Dude. That's sweet.
Matilda: Did you just call me dude?
Orpheous: LOL
Matilda: Is your PC still slow?
Orpheous: Yeah, I was in the middle of a DEFRAG and I got a blue screen.
Matilda: Whoa. Did you update your BIOS?
Orpheous: No, I couldn't find the EXE.
Matilda: Why were you using NTFS instead of FAT?
Orpheous: Hey, do I bug you about using AIX instead of Red Hat?
Matilda: No. But your company doesn't have the same ITIL requirements we do.
Orpheous: At least we're PCI compliant. What's that got to do with the OS?
Matilda: Nothing. Couldn't think of something better.
Orpheous: By the way who did you work with in implementing ITIL?
Matilda: IBM and HP.
Orpheous: Nice...
Read it again and think about that same conversation 20 or even 10 years ago. Many of these acronyms and names weren't even invented then. As our technology changes, our technical jargon changes.
And it's inevitable that some of that jargon makes its way into the consumer lexicon: IM, surfing the web, email, bugs, text (as in the verb).
Acronyms and short names are obviously useful. For people who already understand the technology you're talking about, they're easier on the tongue. But this friendly way of talking about technology belies an underlying complexity which we too easily foist on our customers.
Let's face it--engineers love complexity. I was conducting a new employee orientation yesterday. In going around the room introducing ourselves one of our exceptional new software engineers talked about one of his favorite home hobbies: aerodynamics.
?
I didn't even realize that could be a hobby. He enjoys learning all the math and physics involved with making stuff fly. Don't get me wrong--what a cool and admirable hobby, but it puts a fine point on the fact that engineers are perfectly comfortable with complexity. This fact has two unfortunate consequences, both of which lead to frustration for I.T. customers.
First, our complexity, while delightful and "fun" for us, is confusing and unnecessary to our customers. They want simple answers when they ask simple questions. They don't want technobabble. They want cheap, workable, simple solutions when they come to us with problems. We must shelter customers from complexity in any form. This is not to say we should hide the truth or cover up problems, but these things can be talked about in an easier-to-understand way.
Second, we often create complex processes and bureaucracy to protect ourselves and our customers from the complexity that comes with the territory. This irony is one which alienates our customers further, rendering us "hard to work with," "slow" and "imposing." Process definition and adherence is critical for an I.T. department of any size, but particularly so with ours, given both our depth and breadth of technology usage. But not all process is good process. We should be continually striving to simplify and measure our processes to make sure we're hitting the mark for our customers.
Simplicity. It's the name of the game in I.T. That's why our seventh and final cultural belief is "Make It Easy!"
What an industry we work in! How many emails did you send 15 years ago? How many web pages did you surf? For most of us the answer is zero. Can you now imagine a world without computer technology? So much has changed in such a small amount of time.
All of you techies will probably understand 100% of the following conversation.
Matilda: Whatcha doin?
Orpheous: Surfing the web.
Matilda: Did you know Google uses AJAX?
Orpheous: Yup, but they also use a lot of C.
Matilda: Man, they must be using a serious DBMS.
Orpheous: Yeah, I have a friend who writes SQL for them.
Matilda: They don't use ADO do they?
Orpheous: Yeah right. And their servers run on DOS.
Matilda: LOL.
Matilda: I just got a new mobile device!
Orpheous: A blackberry or a palm?
Matilda: Pocket PC. And it supports both GSM and CDMA!
Orpheous: Cool. Does it support WAP?
Matila: Oh yes! And straight TCP/IP!
Orpheous: Dude. That's sweet.
Matilda: Did you just call me dude?
Orpheous: LOL
Matilda: Is your PC still slow?
Orpheous: Yeah, I was in the middle of a DEFRAG and I got a blue screen.
Matilda: Whoa. Did you update your BIOS?
Orpheous: No, I couldn't find the EXE.
Matilda: Why were you using NTFS instead of FAT?
Orpheous: Hey, do I bug you about using AIX instead of Red Hat?
Matilda: No. But your company doesn't have the same ITIL requirements we do.
Orpheous: At least we're PCI compliant. What's that got to do with the OS?
Matilda: Nothing. Couldn't think of something better.
Orpheous: By the way who did you work with in implementing ITIL?
Matilda: IBM and HP.
Orpheous: Nice...
Read it again and think about that same conversation 20 or even 10 years ago. Many of these acronyms and names weren't even invented then. As our technology changes, our technical jargon changes.
And it's inevitable that some of that jargon makes its way into the consumer lexicon: IM, surfing the web, email, bugs, text (as in the verb).
Acronyms and short names are obviously useful. For people who already understand the technology you're talking about, they're easier on the tongue. But this friendly way of talking about technology belies an underlying complexity which we too easily foist on our customers.
Let's face it--engineers love complexity. I was conducting a new employee orientation yesterday. In going around the room introducing ourselves one of our exceptional new software engineers talked about one of his favorite home hobbies: aerodynamics.
?
I didn't even realize that could be a hobby. He enjoys learning all the math and physics involved with making stuff fly. Don't get me wrong--what a cool and admirable hobby, but it puts a fine point on the fact that engineers are perfectly comfortable with complexity. This fact has two unfortunate consequences, both of which lead to frustration for I.T. customers.
First, our complexity, while delightful and "fun" for us, is confusing and unnecessary to our customers. They want simple answers when they ask simple questions. They don't want technobabble. They want cheap, workable, simple solutions when they come to us with problems. We must shelter customers from complexity in any form. This is not to say we should hide the truth or cover up problems, but these things can be talked about in an easier-to-understand way.
Second, we often create complex processes and bureaucracy to protect ourselves and our customers from the complexity that comes with the territory. This irony is one which alienates our customers further, rendering us "hard to work with," "slow" and "imposing." Process definition and adherence is critical for an I.T. department of any size, but particularly so with ours, given both our depth and breadth of technology usage. But not all process is good process. We should be continually striving to simplify and measure our processes to make sure we're hitting the mark for our customers.
Simplicity. It's the name of the game in I.T. That's why our seventh and final cultural belief is "Make It Easy!"
Subscribe to:
Comments (Atom)