When you consider buying a SaaS make sure that you have a prenap strategy in place (does service deactivation in FAQ section exist, for example).
At least test their support (send them an email with two questions since most support processes cannot handle branching queries) to find out if there is anybody behind the flashy website who is able to respond and guide you.
Making software useable makes it harder to be used while making it easy to be used makes it less usable (across other software).
Search for The Learning CTO, a friend’s blog covering enterprise architecture.
We are testing migration to cloud. The long tech list of requirments is met by both clouds. But in our experience Microsoft wins in terms of suppoort which is by default phone based walk throughs while (paid) Amazon support defaults to emails that tend to be imprecise while their documentation is supperior (with cool Kindle integration). Assuming this is reflection of their cloud strategies (MS keen to build capability and customer base while AWS is optimising) pick the one that is aligned with the stage of your development.
Educate your users to default to searching for tech answers before reaching out to IT support. Google is your user’s friend.
Ok. So you believe in micro services and shadow IT. You add a task management tool, e-payslips, HR app, case management and more. They all make sense since they address a specific need. And then at some point you feel a need to link them first via a single sign on (with a service like Okta) and later as a coordinated work flow. Don’t do this since you will be adding complexity and removing optionality to use the best service for the job since you will be embedding the tools that you selected because they are easily replaceable.
Cloud is simple, right? It just works. Well… no!
Corporates love Outlook. The other reason you would pick Office 365 is the fact you get… Office. But Office 365 is not a cloud native. It’s more of a hybrid trying not to offend old school IT while trying to compete with Gmail.
Think hard if Outlook delegates are worth the work to get on prem IT working with the ‘cloud’.
#TheFTAs Sir Clive Woodward: ‘Who wins in IT, wins’.
If analysis is important, do it all the time. If design is important, do it all the time. If implementation is important, do it all the time. If testing is important, do it all the time. If communication is important, do it all the time.
At Apple “design is part of every conversation”.
Tennis pros win based on the positive actions they take: unreturnable shots down the baseline, passing shots, service aces, and so on. We (beginners) try to emulate our heroes and fail… We hit our deep shots just beyond the baseline, our passing shots just wide of the sideline, and our killer serves into the net. It turns out that mediocre players win based on the errors they don’t make. They keep the ball in play, and eventually their opponents make a mistake and lose the point.
Tennis pros are playing a Winner’s Game, and average players are playing a Loser’s Game. These are fundamentally different games, which reward different mindsets and different strategies.
The smart novice programers play a Loser’s Game, where the greatest reward comes to those who make the fewest and smallest mistakes. That’s not very exciting but works.
What is the best way to succeed? As in all Loser’s Games, the key is to make fewer mistakes: follow examples closely, pay careful attention to syntactic details, and otherwise not stray too far from what you are reading about and using in class. Another path to success is to make the mistakes smaller and less intimidating: take small steps, test the code frequently, and grow solutions rather than write them all at once. It is no accident that the latter sounds like XP and other agile methods; they help to guard us from the Loser’s Game and enable us to make better moves. Search Eugene Wallingford for more info.
My interview for LinkedIn Pulse with Frederique Prevost.