The selected folder is not writable on Canon Scanner

After searching for a couple of hours on the this bug from the scanner software of the Canon MG6250 all-in-one I found the solution. (Based on Mac OSX 10.7.2 Lion)

Basically when the scanner warms up, he shows a preview image of what's on the scanner device. However upon pressing the scan button you get the message "The selected folder is not writable". The first reaction is to look at the destination folder... wrong guess.

If you change your view by clicking the "Show Details" button you will see a bit more options. Change the Image Correction to "Manual" and that's it. You don't need to change anything else. Now you should be able to scan your page.

Clearly a software bug, so @canon, if you read this; fix it please :)

Simplify your product offering

I just read an article on the Dutch iCreateMagazine Apple site (http://bit.ly/uR6MlX).

All credits goes to the author Daan Jeuken but I found it so applicable in my job as EA that I translated parts of the content in English for you.

Focus

... Apple's $ 30 billion worth, but they only have 30 products. If companies have too many different products, none of them will be great. The secret behind this focus is not to say "yes" to every good product, but to say "no" to hundreds of good ideas."

Simplicity

..."Many people think that simplicity is the secret to keeping products simple and close to their original base. That's not true. If something begins to develop, it quickly becomes complex. That is where most people stop; the point is to make something complex into something simple again."

Courage

Over the years, Apple has quite a brutal decisions. So it was a rebel from the floppy disk to be written off and now it seems to do the same with the CD. Do not hold onto ideas from the past, even if they are successful for you. And don't develop those products because others have. "

Dedication

Apple's commitment is closely related to its focus: "If you are not the best you can in a, don't enter that market."

(read full article on http://www.icreatemagazine.nl/nieuws/rondom-apple/apple%E2%80%99s-4-sleutels-tot-succes/ )

If you offer too many products too your customer, you need to support them all. This means that all your energy will be spread out amongst them. I'm referring to spending resources from all departments, sales, marketing, operations, IT ... Divide et impera?

Financially, companies are afraid to simplify their product offering because these products generate revenue. However, due to the lack of a detailed cost picture, very few companies are able to make a valid business case. And without a business case you can't really tell if the products are profitable. 

So, focus, rationalize and keep that portfolio small. Your customers will love it if they actually understand what you are trying to sell them.

Edit: Just read that Google removed 7 products to simplify it's offering: http://googleblog.blogspot.com/2011/11/more-spring-cleaning-out-of-season.html. Even the much announced Wave is discontinued. If the profitability is not their, get rid of it as your customers will only be confused and they'll look at you as a company without focus and vision.

How can IT improve business agility

Just noticed this new info graphic about how students look at their future job environments. Again we see that they want to work wherever using their tools of choice. More and more I believe that a company can get much more effectiveness if the right culture is shaped where employees (or contractors for that matter) need to get empowered to help solve the variable parts of the organization. People should be able to sort out 20% of their tools & processes themselves, without any enforcement from the company pushed through the IT department gates.

I see lots of great ideas when talking with people on the coffee machine, but we find ourselves most of the time closing these talks with "...yeah, nice dreams". Underlying are a number of factors that prohibits us to change:

• company culture; people are insufficient encouraged to change and contribute. Motivation is something that needs to come from the area around you.
• stop thinking short term processes, think about your company capabilities. Of course you need to support people in their job which is similar to supporting their processes, however, don't design your entire IT landscape to it. Figure out what your company capabilities are and cater for that. 
• tools; are you still stuck with those dreadful big fat ERP implementations that require 10 governance bodies to keep it workable for everyone. Suppose that a person from sales has a great idea to get new leads on a way you never thought of. Are you able to get this job done rapidly, even if it is only a temporary activity? "business agility" anyone? 

As usual it's a combination of people, processes and tools. I believe that IT departments can play a big role in this game by:

• Improve your ability to integrate. Forget about the big single ERP that does it all. They do, for the current people and current processes. If you want to be agile you need to be able to swiftly get new parts in and out, the only way to do this efficiently is to improve your integration capability.
• Try to get into a continuous business process improvement routine. Don't just improve the tools, but improve the processes, weed out unused elements and plant new seeds. 
• Review your operations strategy from closed controlled to open and supportive. If someone comes in with a new device for example that they want to use in the organization they want to be able to use it everywhere to access corporate functionalities. Don't smack them with the "not allowed" hammer, work with them, design for consumerization and encourage their empowerment. 

How Parallels defeat VMWare using social media

Couple of weeks ago I upgraded my iMac at home to Lion OS X. To be honest, it was so easy that I had no issue at all clicking the buy button in the Mac Store and pay up the 25 €. Mac was grinding for a few hours and as with my 2 previous upgrades, I could get back to work immediately.

Besides some email indexing issue, the only broken thing for me was the VMWare Fusion software. It didn't start up my windows instances and as such I had troubles creating my invoices (was still on a windows software). 

I searched the web for a solution but found nothing that helped, in fact more the opposite. Official forum topics from VMWare about this topic where people were explaining similar situations just got locked by VMWare leaving their troubled customers in the dark. I went to the competitor and bought their offering, even got a discount if I proved to step over from VMWare. Parallels worked like a charm and I was back on track.

Few days ago I read on the internet that VMWare Fusion is out, not even a mail to a customer. Yes I did receive a mail, in a German which is a language I don't master. Anyway I was a bit upset and vented this on twitter.

VMWare Rant

 A few hours later I got the following message back from, guess who? Parallels:

Answer from Parallels

I was impressed and glad that they're out there watching and protecting their brand and products. Of course my reply was positive:

Thanking Parallels

 And a friendly closure:

Friendly closure

This is a very good example for me how one company clearly wins over another using the power of Social Media. Even if VMWare's new product, version 4.0 might be good, I'll stick with the company that serves me the best.

Well done parallels !

Moved from Drupal to Blogger

Today I moved my blog from drupalgardens over to Blogger. The move is supported by 3 main reasons:
1) Blogger is simpler and more intuitive. All Blog functions are "closer", meaning they require less clicks. The UI is also cleaner and very metro looking.
2) drupalgardens is not moving fast imho, the login process is not working well on the desktop and is even more broke on my iPad.
3) Blogger is free. While the license for using drupalgardens was only $100 per year, I got a rather slow environment which wasn't really snappy. So, now I pay nothing and Blogger just works smoother.

Although I still like drupalgardens, it's scope is more generic than Blogger. If I need a small website with for example eCommerce facilities I would consider Drupal, but for my blogging needs I like Blogger the most.

One last + of Blogger is it's support in social media tools out there like klout, etc.

Well done google :)

Every company needs a Capability Model

In the past 3-4 months I had the opportunity to work with IT management to help formulate their upcoming strategy. It has been a great exercise so far already and without disclosing any information its kind of interesting to walk you through it, who knows you might be struggling with a similar situationy.

Basically you start out by investigating the strategic directions of the business to get an insight into scope and content. In cheaper words; what do they want. Without diving into the execution of anything (remember you are doing "important" strategic work here... stay away from any architecture, solutions or technology ideas), you need to decide where you'll spend your money. Very few companies can do it all. In all of the years I work in the IT industry I noticed a trend that the demand side is always bigger than the supply side :D. So you need to make decisions based on business priorities and feasibility (you could use a feasibility matrix for this if you want).

So, here you are, you think that you understand the business and you selected the topics you want to focus on. Where do you go from here? Well, it's time to create a story which involves slides... lots of it. Just kidding, the lesser slides the better as long as you can transfer your point to your audience. In this case there are several people ("stakeholders") that are interested in this story. You have the senior management (the people that are usually older than you) that wants to know if their business is going to be supported and that IT is taking care of their needs. There could be a board that decide on the budget or any other "upwards" communication path. On the other hand, the same story needs to be told to your own IT staff. The difficulty is to make one story that can serve all of these stakeholders. Your tool of choice here should be a capability model.

So, what is a capability model then exactly? Let's describe how you could produce one to understand the concept. In IT we typically implement business processes, we analyze these and automate them. Sometimes we develop software to automate or sometimes we buy and configure software for it. The level of automation usually depends on your company culture, capacity or budget. An example is: "Every time the sales rep propose a discount of more than 10%, an email is automatically sent to the manager for approval." So, generalizing this would result into "the sales organization should be capable of approving a discount", the magic word here is capable. It implies that the company needs the ability to execute discount approval without specifying how exactly it fits in a given process. Now this capability is a sub capability which is actually part of a bigger capability called Sales Quotation. So, from a birds eye view you ought to be able to describe the high level capabilities that describe end to end what your company does. Here's an example: http://bit.ly/vuleAI. When you have done this exercise, your result is a capability model. While finding the capability model, be sure to make a proper distinction between process and capability like described here as well.

Ok, let's go back to our strategic story, you now have the capability model, what can you do with it? A lot; here are some examples:

• Overlay the IT Architecture: You can draw the big IT systems that you have in house and place them over the capability model. This way you can communicate to management who are usually less tech savvy the place and purpose of your IT landscape.
• Focus area's for change: You can use this model to indicate the area's where your future project will focus on. This is a very interesting way to communicate to the management what part of the business will be impacted.
• The big picture for your project teams: Sometimes, team members don't realize where they are working, they know they have a certain task they're working on, but they usually miss the bigger picture. Using the capability model, you can provide this bigger picture.
• SOA design: Your SOA service taxonomy could be build based on your capability model. I'm not saying every granular capability is a service, but rather that the hierarchy of services can be based on the hierarchy of capabilities. (see also http://bit.ly/p8XOYk)
• ...

Every time we create a model we actually simplify the reality, a capability model is one other way to do this. In TOGAF terms, we could say it is another Viewpoint.

For us, it helped a lot, hopefully for you too :)

Are there really 4 pillars in EA?

As in most EA theories there are 4 pillars; Business, Application, Data and Technology. I know that I'm quite new to the EA scene, but in my experience so far I see that EA is focussed on the Applications and Data pillars.

Business

The business pillar is a given, we use it as input and we support more or less in its shape. But do we really work in this field? I believe the business still sees the Enterprise Architect as an IT guy. They don't concider the Enterprise Architect as a person that helps them shape their shop. In theory it should, in practice I have my doubts. As mentioned last time, I believe this is the job for the Business Architect and in lesser extend the business analysts.

Technology

For the record, this is about hardware, procured software, networking and other nuts and bolts. This domain is getting more and more commodetised on the one hand, and the cloud makes all of this less relevant on the other hand. The result of this is that in this technology pillar Enterprise Architecture is going towards procurement and supplier management. To be honest, not a field where an Enterprise Architect is quite comfortable in.

Applications & Data

Applications and Data is for me the two core aspects where an Enterprise Architect can make a difference. Today it translates in roadmaps, Integration topics like SOA and EDA. Data topics like MDM, etc. this is where the Enterprise Architect will have his focus on. I don't believe completely on the view from Jeff Scott of "there's an app for that" approach in 20 years from now. Yes, we will have more apps; I even downloaded OS X Lion last night from the App Store from Apple, went to sleep and in the morning I had a new OS installed and working like a charm. However, even in an app world we will still face the integration music, so at best Enterprise Architects migt become app integration specialists :). One thing the app move does, makes everything more simple at least from the user's point of view. I'm thinking, when things become more simple we would have less need for the governance of it, so this might be another topic we can drop from the Enterprise Architects role...

Business Architect

Since a few days I'm telling various people about a missing role/person in the company. Whilst I may be an Enterprise Architect since a couple of months now; getting things done and organized in the IT departments seems just so easier than it is in the business side. I know it is due to my IT background that it just feels much more natural and hence you roll much better in the IT space. I consider myself doing a relative decent job (as a youngster in this role) in my natural habitat; acting like oil to make the machines run smoother again.

I believe a Business Architect is actually a person much needed to act as a counter part of the more tech savvy enterprise architect. This person should be the one that ties up the different departments and make them act according to the companies strategies; better yet, he should be involved in aligning the various departmental strategies into one coherent direction. Enterprise Architects coming from the IT corner will have a hard time to get this done; I believe this business oriented role is much more the destination for let's say a business analyst that never worked in IT.

An Enterprise Architect can get early involvement in the strategic exercises but will usually be coordinating between the business and IT; much less getting the ducks of every business department on a row, so there's definitely some work left for the business architect.

Funny when I was thinking all of this, that I read this article http://www.cio.com/article/684344/The_6_Hottest_New_Jobs_in_IT where the Business Architect snatches today's hottest IT role….

Lean back versus lean forward products

If you compare the different form factors that are out there today ranging from smart phones to tablets, thin laptops, desktop replacement laptops there's one could classify these devices into two categories. Either it's a lean back device that is used most often for reading and consuming information or either it is a lean forward device where digital content is being created on. This is he differentiator that drives both markets and that therefore a tablet will never replace a laptop or the other way around, they are both here to stay.

TOGAF training

Architecture Development Method

Last week I went to Utrecht to get educated on TOGAF, a framework for enterprise architecture.

The first day was a bit messy to get there. Arriving in Utrecht I took a cab to the wrong address but eventually I got on my destination, albeit a bit later than expected.

In this initial day we looked at the overall scope of TOGAF and its Architecture Development Method (ADM). At the end of the day, I wondered if TOGAF could be applied in an agile/lean manner, surely something I will look in to.

During the other days, I constantly tried to imagine how TOGAF could be used for the customer where I'm working for at the moment. I do believe that I can go back to work next Monday with a better understanding on how to approach the Enterprise Architecture journey. The good thing about the methodology is that it not only provides a guidance during the EA exercise, but also guidance on how to set it up. This is especially interesting for the situation that I'm in at the moment.

I also found it very interesting to learn how TOGAF deals with the management of artefacts that are produced or brought into the Enterprise Architecture. I believe that the repository that I've started with will look a bit more different from now on. However, the simple SharePoint setup is still sufficient for this job if you ask me.

In this course I really learned that demystifying complexity by using various viewpoints for the different stakeholders is a really important aspect. If this helps to get the stakeholders in line, then it is a job well done. Secondly there is time and space foreseen for finding and dealing with cross project synergies, a topic that I believe is much needed in my current company. The part about governance was a bit heavy and tuned to the bigger enterprises, perfectly fine I just need to figure out how it can be downscaled to the appropriate size for us.

I had one disappointment on the chapter about requirements management. In my simple mind I was misled by the size of the circle on the ADM and thus I had pretty high expectations about it. It came out that TOGAF specifies the importance of it, but not really a way to accrue or manage these requirements. I reckon that this is subject for a different course :)

I would like to thanks Rienk de Kok of the-unit (www.the-unit.nl) for his dedication during the course, he's a good instructor that I would advise without a blink. Secondly I would also like to thank the other 11 attendees as they made the course even more interesting.

Next step is to turn the theory into practice, but that's food for a next post.

The journey begins

The first week

Previously I wrote about the ramp up towards the Enterprise Architecture in my company. I would like to continue on this topic by giving a short story on the first week.

In the past week I continued to tour the company explaining about enterprise architecture to make sure no one got excluded from that story. The reactions seemed positive and people look forward to it. So far the message was spread in the IT organisations as they were closest to me, always easier to speak to kindred spirits :) However, I know that a similar message has to be told to the business, but therefore I'll need a different text with the same meaning.

Starting the enterprise architecture is not something that is easily done. I consider that a lot of preparation is needed, but we still want to provide short term value. As said in the previous topic, a lot is about communication for us at the moment, connecting people. Openly discuss topics even across project boundaries and be transparently in that communication. Additionally we also need a better document management solution than a network share that just doesn’t cut it for this purpose.

Luckily the company just rolled out Office2010 and SharePoint, so I took advantage of the situation and immediately started populating all architectural artefacts that I knew off into SharePoint. The intent is to attribute all documents in their based on the TOGAF meta model so that we can use SharePoint as kind of an architecture repository and a communication channel at once.

Besides setting up this environment, I did spent some time on the project level where I got invited by my colleague architects. They look forward to address the cross project concerns as they use to fall out of the equation at the end of the day. I do hope to find a way to gather and consolidate all these additional requirements and bring these forward to the Architecture forum (IT management) where they can be evaluated and perhaps even planned in the IT roadmap. 

Next thing on the menu is a TOGAF course in the Netherlands that will hopefully provide me with a good deal of theoretical knowledge to take our Enterprise Architecture a step further.

Stay tuned :)

The face of a new target enterprise architecture

One of the tasks on my menu is to facilitate and drive the exercise of our target Enterprise Architecture, in short, our big picture, the master plan. The question is, do we derive it from our current situation but an improved version of it, sort of, will we start over and fix all the pain points of today. But what guarantee do we have that we'll do it the right this time? Will we end up a few years down the road in the same situation as we are today, getting the feeling that our technology is hampering the companies agility and innovation. This brings up the question if we actually need to invest big time into our future, maybe we should just go into the direction of throw away architectures, much like we replace our dining room every now and then with low budget Ikea furniture. Would this make us much more agile, would this result into a continuous moving and transforming company?

When I think about it, I believe some things are stable over the the years, consider a purchase order or an invoice, they're still around since the early days, there still similar today than my first school example a few decades ago. So, where is the variability then, is it in the products, they do change continuously and more and more rapid everyday for most companies. I believe the difficulty lies in the zone where the variable meets the invariable. Today most ERP's and custom (legacy) front/back office platforms have a polished end to end process. Sales tools, CRM systems etc, all mix the complete business processes together. The data that is involved with for example a traditional print advertisement is completely different that the data involved with an online ad. It are these differences that really change the internals of ERP's and custom build platforms. The business people they do not always understand, for them it is just another product, true some characteristics that are different, but they usually don't understand the fuzz from IT departments when they conceive new products.

So, what if we would architecture our IT landscape in such a way that the stable invariant processes are based on solid proven enterprise packages. The more the nature of the business process and its related data/information gets variant we want to structure this as minimum as possible, don't make it too rigid because it can change over night. With this attitude we are not bothered if we throw away something. This brings me to the next question then, what would we use to support the more variable business processes? Well, I believe that today we see more an more consumerization going on, where consumer products our serious alternatives to use as complementary means in the enterprise. For example, just replace a rigid ever changing discount approval workflow setup (that is usually changed when it ready) by giving sales force a communication tool like skype and they can just simple ask their manager if they are allowed to give that extra discount for the customer they're facing. Does it really need to be so well structured, controlled, formal, rigid, etc or is it exactly this space that warrants business agility if we do provide freedom.

Today employees are far more advanced PC and internet users than 10 years ago. I always said in modernization projects that the tools everyone uses at home - from operator to the CEO - influence the wishes of the next platform they have in mind past the green - and gray screen application era's. Today I believe more and more that these very same tools will not only be an inspiration for the enterprise but will be the very products used in the enterprise itself.

There are still a lot of other questions, for example how do managers monitor, process and correct their operations without proper information or without their important KPI's? It is my believe that simple and seamless BI will play an important role in this, so BI will move from an support/optimization position to a crucial core component of the overall architecture.

All of this could lead to an enterprise that operates on solid proven standardized platforms complimented with commodity/productivity tools and consumer products. Make sure you serve the business user properly on the stable processes and empower them in the variable bits and give them the means to be creative and innovative.

Enterprise Architecture start-up

The beginning of the Enterprise Architecture

A few weeks ago the project I was working for was put on hold, 7 months of my time to waste? No, definitely not, I learned a great deal on the overall organisation and had the opportunity to look into most of the companies business processes.

After the project, I started working on a proposal for Enterprise Architecture, something the company is in need of and they were looking for an Enterprise Architect anyway. I figured, I can do a lot of stuff that this new (Enterprise Architect) lad can pickup later on, who knows, I might be able to join him and work together in the space of EA.

Weeks went by and the my story became more and more clear, we only had to wait for the Enterprise Architect to arrive. In the meanwhileI I started to get in touch with people and communicate my message that EA will be there and that it will offer a great deal of guidance in our ever transforming company. I invited myself to a lot of architectural flavoured meetings and gave my recommendations for topics like SOA etc. Eventually it came to the point where I brought my message to the director level and even to the CIO who were all very interested as they saw some things that could help them with their struggling IT strategy and roadmap. It became apparent  that I had to step forward and so I did; and so the companies Enterprise Architecture journey began.

Ok, we have the attention, what now?

Right, here we are, lacking years of experience in various EA frameworks like TOGAF, Zachman, or any other (btw, used to be a software architect most of the time), however, I believe I have a number of good ideas, none of them are structured into a big master plan though. When I was in the CIO's office the other day, he asked me some questions like; we need to get our IT strategy right by the summer (in a few months), can you have the new to-be architecture ready by then. Walking out of the office I honestly had no idea if I could pull it off,  I know I'm capable, just don't know if the CIO and I are, time-wise on the same level.

So, to the drawing board. I kind of figured that we need an approach first:

1. Communication: align on tooling, align on business language (glossaries), align diagram notations, centralize documentation and communicate as much as possible about the existence of the EA. 
2. Guidance: Assist the architects in topics like SOA, train, educate them on the little agreements and visions that we have so far. FInd and advocate industry standards and keep an eye on industry trends.
3. Advice: Be there for the strategical level to form an advisory body and to make recommendation. Provide architectural input as soon as possible when new projects are being conceived.
4. Governance: I know we have to get to a pragmatic level of control, with room for creativity & innovation, how it will look like is unclear for me at the moment.

So if this is the path that we'll follow, what are the actual deliverables that are going to be produced and which of these bring the most value in the short term both to strategic, tactical and operational level? I first thought on getting a good picture of the As-Is situation, but after reading Jon's  post about "To Be or Not To Be" I changed my mind, so that's one I'll park for now. In the company, one of the "broken" things sterns from data ownership, more specifically I see teams fighting (bit strongly expressed, but you get the idea) for data and functionality for which I found a good paper from MIT "Information Politics", still have to read it though.

Right, this is the EA start-up in a nutshell, lots of reading to do though, however I feel that I need to catch up quickly to deliver some value, so need to be smart about it, but that's some food for next post :)

On Twitter

For those who are interested, you can follow me on twitter which I'll use for my professional career. Most of my ups and downs in the journey of Enterprise Architect will be posted over there. As allways it might be usefull for some1 following similar directions. Enjoy.

twitter: @eriklenaerts

Techdays 2011 - 26 April

Techdays is one of the events that I usually go to every year. True, my background lies within the Microsoft technology but has broadened over the years. All with all, I still enjoy this event as it brings me up to speed in the Microsoft world in 2 condensed days. Looking forward to some talks, like the ones from Scott Hanselman, from who it is always pleasant to hear.

On top of that, it's in my home city, Antwerp, so that saves me a drive as well :)

More info at: http://www.microsoft.com/belux/techdays/2011/

Conceptual Requirements

Defining a product comes down to specifying its requirements. But what happens when the business is unable to define its requirements?

When there are no business architects or analysts, IT staff will assist in the requirements gathering process where they help in structuring the thoughts of business people. This could be done in workshops with various business functions like sales, marketing, finance, legal, etc.. Going down to the level of detail that is really helpful for IT will take a few iterations. After the first round we can produce conceptual requirements that become the basis for more detailed requirements later on.

One possible way, that worked out for me, was to define the conceptual requirements in a format as if I was reading a commercial data sheet from the ideal product in mind. It would describe features and benefits of the super system that would fall down from heaven into our laps. It would contain a lot of open ends and simple examples to give a lot of room for brainstorming, but at the end of the day, it will deliver ourself a way to define the scope of the project.

The conceptual requirements can eventually be used in various ways, either they will be refined in more detailed requirements for a procurement process or they can be used as first input in the product backlog of an agile development team. High level requirements, feasibility studies etc. can all be subject to the initial concepts.

For the architect, it will lay down the areas of concern, the directions where extensibility is key, areas with high scalability or security needs. Conceptual requirements usually fit perfect in the mind of the architect who is usually the person with "more or less going 17 degrees north direction over the coming years"-insight.