Above is a picture of the SIM cards – as you can see, they vary a lot, but the only parts that matter to us are the contacts which are common to the MicroSIM and SIM.  Electronically, the SIM and MicroSIM are the same so we can cut the rest away and not worry (so long as we are careful).

To begin with, line up the three contact on the MicroSIM with the same ones on the SIM card.  You can just look for the 2 centre lines and make sure they are in line and that the top of the MicroSIM is straight. Then get your meat cleaver and press down gently to score a straight line.

Cut along the score line carefully.  Once you have done this, line the top of the SIM with the MicroSIM and you should see that the contacts are aligned.

Turn the SIM & MicroSIM round 180 degrees, line up the bottom and repeat with the meat cleaver, then cut along the score line once again.

The SIM should now be the same height as the MicroSIM – we are halfway there!

Line up the centre of the MicroSIM with the SIM so that we can be sure it will be aligned within the iPhone 4G/HD or iPad.

Repeat the process with the meat cleaver and scissors, then you should have a SIM which is almost the right size, save for the top edge and corner.

Once again, repeat the process with the meat cleaver and scissors, then you should have a SIM which is the same size apart from the corner.

Cut off the corner of the SIM card – you can just use the meat cleaver for this if it is nice & sharp.

Your SIM card is almost ready to go in to your iPhone 4G/HD or iPad.  As you can see, the AT&T MicroSIM has slightly rounded corners. Use your meat cleaver to take off the tiniest of amounts.  Remember, you can take more off, but you can’t put it back on.

Your SIM should now fit in your iPhone 4G/HD or iPad MicroSIM tray.

Gently insert it in to your iPhone 4G/HD or iPad 3G.

You should see your network indicator change to the network of your SIM card – well done!

Go in to Settings, Cellular Data

Then go in to APN and enter the access point.  If you are using Vodafone in the UK, the APN is internet.

Press the Home button on your iPhone 4G/HD or iPad, go in to Safari and browse away with your new iPhone 4G/HD or iPad 3G!

Enjoy IPhone 4G and IPad with your normal SIM Card.

Adnan Arif

You’re welcome. This nerd/dork/geek/dweeb Venn diagram should save you a lot of time and frustration in the future.

What is Google Wave?

Google Wave is a real-time communication platform. It combines aspects of email, instant messaging, wikis, web chat, social networking, and project management to build one elegant, in-browser communication client. You can bring a group of friends or business partners together to discuss how your day has been or share files. In other words Google Wave is an online tool for real-time communication and collaboration. A wave can be both a conversation and a document where people can discuss and work together using richly formatted text, photos, videos, maps, and more.

Google Wave was the brainchild of a team based out of Sydney, Australia. The core team members are two brothers, Jens and Lars Rasmussen, and lead project manager Stephanie Hannon, all of whom were involved in Google Maps previously.

Google Wave has a lot of innovative features, but here are just a few:

• Real-time

In most instances, you can see what someone else is typing, character-by-character.

• Embeddability

Waves can be embedded on any blog or website.

• Applications and Extensions

Just like a Facebook application or an iGoogle gadget, developers can build their own apps within waves. They can be anything from bots to complex real-time games.

• Wiki functionality

Anything written within a Google Wave can be edited by anyone else, because all conversations within the platform are shared. Thus, you can correct information, append information, or add your own commentary within a developing conversation.

• Open source

The Google Wave code will be open source, to foster innovation and adoption amongst developers.

• Playback

You can playback any part of the wave to see what was said.

• Natural language

Google Wave can autocorrect your spelling, even going as far as knowing the difference between similar words, like “been” and “bean.” It can also auto-translate on-the-fly.

• Drag-and-drop file sharing

No attachments; just drag your file and drop it inside Google Wave and everyone will have access.

While these are only a few of the many features of Google Wave, it’s easy to see why people are extremely excited.

Terminology

Google Wave actually has its own lingo – yes, you have to learn a few definitions if you’re going to really understand this new communication platform. Having knowledge of these terms will help you understand more about Google’s newest project.

• Wave

A wave, specifically, refers to a specific threaded conversation. It can include just one person, or it can include a group of users or even robots (explained below). The best comparison I can make is that it’s like your entire instant messaging (IM) history with someone. Anything you’ve ever discussed in a single chat or conversation is a wave.

• Wavelet

A wavelet is also a threaded conversation, but only a subset of a larger conversation (or a wave). It’s like a single IM conversation – a small part of a larger conversation and a larger history. Wavelets, though, can be created and managed separately from a wave.

• Blip

Even smaller than a Wavelet, a Blip is a single, individual message. It’s like a single line of an IM conversation. Blips can have other blips attached to them, called children. In addition, blips can either be published or unpublished (once again, it’s sort of like typing out an IM message but not yet sending it).

• Document

A document actually refers to the content within a blip. This seems to refer to the actual characters, words, and files associated with a blip.

• Extension

An extension is a mini-application that works within a wave. So these are the apps you can play with while using Wave. There are two main types of extensions: Gadgets and Robots

• Gadgets

A gadget is an application users can participate with, many of which are built on Google’s OpenSocial platform. A good comparison would be iGoogle gadgets or Facebook applications.

• Robots

Robots are an automated participant within a wave. They can talk with users and interact with waves. They can provide information from outside sources (i.e. Twitter or they can check content within a wave and perform actions based on them (i.e. provide you a stock quote if a stock name is mentioned).

• Embedded Wave

An embedded wave is a way to take a Google Wave and the conversation within it and place it on your website. Users could use this as a chat room, as a way to contact you, or for something more.

Wave Gadgets

A Wave Gadget is one of two types of Google Wave extensions. Gadgets are fully-functional applications. According to Google, gadgets are primarily for changing the look and feel of waves, although this seems to only scratch the surface of the potential of a wave gadget.

First: almost any iGoogle or OpenSocial gadget can run within Google Wave. That means thousands of applications that have been already created will work in Google Wave. Second: a gadget built within Google Wave can take advantage of live interaction with multiple users. This means something like a live online game with active participation from all users. In that way, it has similarities to Facebook or MySpace applications, which take advantage of your friend network to make games, quizzes, and applications more meaningful and useful.

Gadgets are specific to individual waves, rather than to specific users. Thus, it’s not like having a Facebook app on your profile – the gadget belongs to everyone within the wave. They also do not have titles, to better integrate with the actual conversation. Some of the gadgets already built include a Sudoku gadget, Bidder (which turns your wave into an auction), and Maps (which allows for collaboration on a Google Map).

For a more technical explanation, be sure to check out Google’s Wave Gadgets Tutorial.

Wave Robots

Robots are the other type of Google Wave extension. Robots are like having another person within a Google Wave conversation, except that they’re automated. They’re a lot like the old IM bots of the past, although far more robust. Robots can modify information in waves, interact with users, communicate with others waves, and pull information from outside sources.

Because it acts like a user, you can define its behavior based on what happens in the chat. You could build one as simple as “change the word dog to the word cat” or one as complex as a fully-functional debugger. We’ll probably start seeming some very advanced robots in the near future.

Some of the robots already in service include Debuggy (an in-wave debugger), Stocky (which pulls stock prices based on stock quote mentions), and Tweety (the Twave robot, which displays tweets inside of a wave).

A more advanced explanation is available at Google’s Wave Robots Overview

Wave Embeds

Wave embeds are a little more complex than embedding a YouTube video onto your blog, yet in the end, that’s really what Google Wave Embeds are: a way to take Google Waves onto a third party website. Embedded Waves support many of the functions of the actual Google Wave client, including dragging-and-dropping files.

While the Wave Embeds is still very early stage, Google has already built two: YouTube Playlist Discuss and Multiple Extensions Embed. The former allows you to discuss a YouTube video via a wave and the latter allows for interaction with multiple waves on the same page.

One possibility: Google Wave Embeds may be a real-time replacement to static comments. If Google perfects wave embeds, you could even see YouTube.com comments replaced with waves, although it is way too early to make any calls on the potential of this.

Google’s Wave Embed Developer’s Guide has more advanced information embedding waves.

References for Google Wave

Still can’t get enough of Google Wave? This collection of links and articles will help you understand this new product even better:

• Google Wave Federation Protocol: Google has provided some community principles, architecture information, and more detailed definitions on their Wave protocol webpage.

• Google Wave API: For developers interested in building applications for Google Wave, be sure to check out the Wave API website.

• Google Wave Updates: Haven’t signed up for Google Wave yet? Here’s the sign-up form.

• Learn about its usage: There are tons of ways to use Google Wave–here are just a few examples to get you thinking

• Google wave extensions: Check out some of the extensions built during the developer preview.

• Story behind Google Wave: learn about how this whole thing started.

• Google Wave Developer Preview at Google I/O 2009: watch the whole developer preview video at I/O 2009.

• Featured sample apps: list of few featured apps for Google Wave.

Hope this help you understand Google Wave in detail.

Adnan Arif

here are the actual slides from the presentation.

When we’re creating sites, we act as though people are going to pore over each page, reading our finely crafted text, figuring out how we’ve organized things, and weighing their options before deciding which link to click. What they actually do most of the time (if we’re lucky ) is glance at each new page, scan some of the text, and click on the first link that catches their interest or vaguely resembles the thing they’re looking for. There are usually large parts of the page that they don’t even look at. We’re thinking “great literature” (or at least “product brochure”), while the user’s reality is much closer to “billboard going by at 60 miles an hour.”

As you might imagine, it’s a little more complicated than this, and it depends on the kind of page, what the user is trying to do, how much of a hurry she’s in, and so on. But this simplistic view is much closer to reality than most of us imagine. It makes sense that we picture a more rational, attentive user when we’re designing pages. It’s only natural to assume that everyone uses the web the same way we do, and—like everyone else—we tend to think that our own behavior is much more orderly and sensible than it really is. If you want to design effective web pages, though, you have to learn to live with three facts about real-world web use.

“Why are things always in the last place you look for them? Because you stop looking when you find them.”— Children’s riddle

FACT OF LIFE # 1:

We don’t read pages. We scan them.

One of the very few well-documented facts about web use is that people tend to spend very little time reading most web pages. Instead, we scan (or skim) them, looking for words or phrases that catch our eye. The exception, of course, is pages that contain documents like news stories, reports, or product descriptions. But even then, if the document is longer than a few paragraphs, we’re likely to print it out because it’s easier and faster to read on paper than on a screen.

Why do we scan?

• We’re usually in a hurry.

Much of our web use is motivated by the desire to save time. As a result, web users tend to act like sharks: They have to keep moving, or they’ll die. We just don’t have the time to read any more than necessary.

• We know we don’t need to read everything.

On most pages, we’re really only interested in a fraction of what’s on the page. We’re just looking for the bits that match our interests or the task at hand, and the rest of it is irrelevant. Scanning is how we find the relevant bits.

• We’re good at it.

We’ve been scanning newspapers, magazines, and books all our lives to find the parts we’re interested in, and we know that it works.

FACT OF LIFE # 2:

We don’t make optimal choices. We satisfice.

When we’re designing pages, we tend to assume that users will scan the page, consider all of the available options, and choose the best one. In reality, though, most of the time we don’t choose the best option—we choose the first reasonable option, a strategy known as satisficing (a cross between satisfying and sufficing). As soon as we find a link that seems like it might lead to what we’re looking for, there’s a very good chance that we’ll click it.

So why don’t web users look for the best choice?

• We’re usually in a hurry.

“Optimizing is hard, and it takes a long time. Satisficing is more efficient.”

• There’s not much of a penalty for guessing wrong.

Guessing wrong on a web site is usually only a click or two of the Back button, making satisficing an effective strategy. (The Back button is the most-used feature of web browsers.)

Of course, this assumes that pages load quickly; when they don’t, we have to make our choices more carefully — just one of the many reasons why most web users don’t like slow-loading pages.

• Weighing options may not improve our chances.

On poorly designed sites, putting effort into making the best choice doesn’t really help. You’re usually better off going with your first guess and using the Back button if it doesn’t work out.

• Guessing is more fun.

It’s less work than weighing options, and if you guess right, it’s faster. And it introduces an element of chance — the pleasant possibility of running into something surprising and good.

Of course, this is not to say that users never weigh options before they click. It depends on things like their frame of mind, how pressed they are for time, and how much confidence they have in the site.

FACT OF LIFE # 3:

We don’t figure out how things work. We muddle through.

One of the things that becomes obvious as soon as you do any usability testing—whether you’re testing web sites, software, or household appliances—is the extent to which people use things all the time without understanding how they work, or with completely wrong-headed ideas about how they work.

Faced with any sort of technology, very few people take the time to read instructions. Instead, we forge ahead and muddle through, making up our own vaguely plausible stories about what we’re doing and why it works. And the fact is, we get things done that way. I’ve seen lots of people use software and web sites effectively in ways that are nothing like what the designers intended.

Most web designers would be shocked if they knew how many people type URLS in Yahoo’s search box.

Why does this happen?

• It’s not important to us.

For most of us, it doesn’t matter to us whether we understand how things work, as long as we can use them. It’s not for lack of intelligence, but for lack of caring. In the great scheme of things, it’s just not important to us. (Web developers often have a particularly hard time understanding—or even believing—that people might feel this way, since they themselves are usually keenly interested in how things work.)

• If we find something that works, we stick to it.

Once we find something that works—no matter how badly—we tend not to look for a better way. We’ll use a better way if we stumble across one, but we seldom look for one.

What I suggest – if your audience is going to act like you’re designing billboards, then design great billboards.

Adnan Arif

Who is Systems Architect?

The Systems Architect is the high-level designer of a system to be implemented. The systems architect establishes the basic structure of the system, defining the essential core design features and elements that provide the framework for all that follows, and are the hardest to change later. The systems architect provides the engineering view of the users’ vision for what the system needs to be and do, and the paths along which it must be able to evolve, and strives to maintain the integrity of that vision as it evolves during detailed design and implementation.

Responsibilities of a Systems Architect

A software architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the business needs, satisfies user requirements, and achieves the desired results under given constraints. This article describes the myriad responsibilities of a software architect, and attempts to identify human personality traits that naturally aid a person in such position.

• An architect abstracts the complexity of a system into a manageable model that describes the essence of a system by exposing important details and significant constraints.

• An architect maintains control over the architecture lifecycle parallel to the project’s software development lifecycle. Although an architect may be most visible during the requirements and design stages of a project lifecycle, he or she must proactively monitor the adherence of the implementation to the chosen architecture during all iterations. Architecture on paper is fruitless unless implemented proficiently.

• An architect stays on course in line with the long term vision when projects’ scope creep attempts to manipulate software architecture in a certain way in order to satisfy the desires of myriad stakeholders. An architect must focus on actions that produce results early while staying on course for the long term. When project variables outside of one’s control change the architect must adjust the strategy given the resource available while maintaining the long term goal.

• An architect progressively makes critical decisions that define a specific direction for a system in terms of implementation, operations, and maintenance. The critical decisions must be faithfully made and backed up by understanding and evaluation of alternative options. These decisions usually result in tradeoffs that principally define characteristics of a system. Additionally these decisions must be well documented in a manner understood by others.

• An architect sets quantifiable objectives that encapsulate quality attributes of a system. The fitness of the architecture is measured against set marks.

• An architect works closely with executives to explain the benefits and justify the investment in software architectures. This may be done by participating in business process re-engineering activities, by using Cost Benefit Analysis Method, or by measuring the level of component / architecture re-use between projects with the help from the software process improvement team. Software architect must be effective in order to deliver results that are meaningful to the projects that have an impact on the bottom line that result in greater profits.

• An architect inspires, mentors, and encourages colleagues to apply intelligently customized industry’s best practices. Educating the recipients and participants of system architecture is essential to successfully selling the chosen architectural path. Specifically the stakeholders must be able to understand, evaluate, and reason about software architecture. If an architect is the only one who can read and understand documented system architecture, then he has failed to integrate his best practices into the organizational culture.

• An architect fights entropy that threatens architect’s structural approach to problem solving. It’s an architect’s job to keep the inertia going once the project is in progress. He or she must convince all relevant stakeholders that the chosen approach is sound – moreover the chosen architectural solution must be well explained and justified. The benefits of implementing a system in a particular way must be explained not only in terms of “that’s the right pattern for this problem,” but also to demonstrate the measurable benefits – such as easier integration. For example, in a product line approach an architect must be able to demonstrate how the subsequent projects will be easier to implement due to the presence of a common base from which subsequent work can be done.

• An architect creates and distributes tailored views of software architectures to appropriate stakeholders at appropriate intervals. For example, a customer may demand to become more involved with a project and they may need to know an abstract view of a system on the level understood by them. A government customer may require an architect to demonstrate early in the project how a given system meets High Level Architecture requirements for a specific framework. It’s the architect’s responsibility to identify and present a sufficient level of information that a customer needs.

• An architect acts as an agent of change in organizations where process maturity is not sufficient for creating and maintaining architecture centric development. If the concept of software architecture is not well recognized in an organization it may be a “tough” sell to formally recognize the role of software architecture in a SDLC. Without senior management commitment and without mature software development process, architecture of the system on paper may not reflect the actual architecture of a system.

Role of a Systems Architect

Architect’s Personality and Other Traits

• An architect is a human filter that process complexities and outputs an abstract high level model of a system. Conveying the output to the stakeholders requires excellent communication skills – written, verbal, and presentational.

• An architect is a negotiator. The method of principled negotiation should be the tactic of choice for an architect. This method is most suitable in contrast to soft or hard negotiation method, because it seeks mutual cooperation between an architect and project stakeholders. An architect will be expected to deliver better, faster, and cheaper, but since only two-way combo can be selected an architect must negotiate to decide which aspects of a system will be considered first and under what conditions.

• An architect must convey a sense of credibility and trust; an architect must be perceived as successful. An architect can attain such status with his prior successful experience, formal training in the field (certifications in the future), and by his or her ability to deliver successful and relevant architectural artifacts through every stage of the SDLC.

• An architect believes in his ability to perform well. In a leadership position attitude is everything – if the passion for success is absent, then an architect must step down from the leadership pedestal.

• An architect must be patient and resilient, as the only thing constant is the change itself. Since software architecture has direct influence on the quality characteristics of a system, an architect will interact with a great number of people with a full spectrum of personalities. He or she must quickly adapt to the way stakeholders operate, as it’s not possible or feasible to expect them to speak the language of an architect.

What do you need to become a Systems Architect

First, to be considered for a Systems Architect position, it typically requires several (usually 8-10+) years of IT experience with an established reputation as an expert within a specific area. For example, many of my fellow architects have deep knowledge in at least one of more areas including security, collaboration, middleware, networking, mobile devices, governance, Service Oriented Architecture and messaging, mainframe development, open systems development, Windows development, web development, storage, database, and specific vertical business applications.

Once you have had proven success and a solid background in a few technology areas, it may be time to consider working with the broader picture for design and planning – which is why many consider the Systems Architect role.

To answer what training is best, I’d like to look at what skills are most needed:

1. Soft Skills

Probably the most overlooked and yet probably the most important skill that differentiates those that choose this path. Most companies consider the Systems Architect role as equivalent to a middle manager role and also expect the soft skills to be on par with this “peer group.” This role requires a significant amount of selling the ideas, concepts, plans, direction, and evaluations to both developers and IT people as well as to business and technology management teams.

Top soft skills to consider:

• Verbal Communication Skills. Consider courses on making and delivering presentations, becoming more influential (think sales types of courses), and any improvement in language. A good option may also be Toastmasters to allow for practice in making presentations in front of groups.
• Written Communication Skills. Start reading the documentation that is produced internally by the architecture groups. There are also many classes that can assist that range from email to full evaluation documentation and architecture drawings. See what the current group is producing today and start working on creating similar documentation for your own group or area.
• Interpersonal Communication Skills. Get an honest assessment of your own interpersonal skills and be aware of them as you work with others. Learn how to become more flexible and adjust to a given situation is extremely important. A Systems Architect has to work with a wide variety of people that include upper management, middle management, technology developers, support groups, project managers, vendors, and customers. Look for courses in areas that you feel you need some help.

2. Functional Skills

A Systems Architect role is ever changing depending on the current strategy and priorities of the company. It is important to be always in the mode of continuous learning. I usually aim for at least 2-3 new training classes or seminars every year in addition to regular reading on new technologies or architecture best practices and background. There are a few Systems Architecture and Enterprise Architecture courses or conferences that can help to provide many of the concepts shown below.

What should you read and learn

Some of the required reading or classes should include the following:

• Enterprise Architecture Frameworks. It is important to have an understanding of the main architectural frameworks which includes POSIX, TOGAF, Zachmann, DoDAF, and FEAF. Determine which one that you and your company have adopted – or more likely what variation or combination of framework.

• Architecture Diagram Examples. There is no standard format for these but an investigation of the ones internal to the organization as well as the various examples of Conceptual, Logical, and Physical diagrams. It is best to have an understanding of the differences of each of these diagrams along with various techniques for modeling dependent on the type of project and solution.

• Unified Modeling Language or UML. This will provide a background understanding and good foundation for many diagrams and documentation. UML is a method of defining an abstract or complex solution using a standardized visual model.

• Business Strategy Development. Understand the current strategies, how they were developed, and who developed them. Understand the impact based upon business, applications, and infrastructure.

• Technology Lifecycle and Evaluation. Evaluation of current and new technologies and products and their lifecycle to include emerging technologies to retired technologies. This includes making choices of when to introduce these new technologies and when they should be replaced.

• Architecture Principles and Policies. Architecture decisions need to be made based upon a common direction. Review your company’s or other company’s written principles and policies.

• Governance and Policies. This will depend on your given vertical marketplace but include different organizations such as SOX or ISO.

• Vendor Management. Related classes could include ethics and legal courses in addition to understanding how to develop Request for Information and Request for Proposals.

• Project Management. Many Systems Architects may also be required to lead the technology portion of a project.

Who is Right for the Architect Role?

Some personality tendencies that I personally have identified are as follows. Ask your self do you posses these attributes:

• Builders – these are people who are most gratified when “building”, whether it be building a network from scratch or a program from scratch we get bored easily with the same work day to day. We typically build, and move on, build, move on.

• Problem Solver – do people come to you when they have a problem? If you are able to take a very complex and substantial problem and break it down into meaningful “bites” to craft a solution, you are a problem solver.

• Effective Communication – SAs rely heavily on communication. We translate “business” language to “technology” language.

• Technology Generalists – remember Architects don’t typically roll up their sleeves and actually do the programming, although the ones who have programmed in the past gain the respect of their programming team members much easier. An Architect will typically have multiple lead developers reporting up to them in a project environment. So, don’t get TOO good and any one thing (other than building and problem solving!). Architects are typically generalists that draw on a broad range of expertise.

Why We Need Architects

Experience tells us that without having someone (or a team, for larger projects) responsible for the architecture, the architecture is no-one’s priority, and it gives way to what is on the priority plate—features that need to be released soon!

My Advice

It’s hard to say what’s the exact formula to be on top of the IT stack but here is my advice.

• Work in higher visibility IT roles; director level or above. This is where you learn your political savvy, your understanding of using IT to address business challenges, and hone your communication.

• Sign up for project work. Serve as Project Manager or development lead on high visibility / high impact projects. When you are working on a project, you are essentially engaging in implementing a solution to a problem. Get a PMP certification if you can.

• Stay current in technology. A year might as well be a century in IT. Always stay current on technology, its use, different methodologies, approaches, etc.
• Try to get a job in an organization that is known for its technical human resource typically a large IT consulting firm.

There I said it all. Wish you all the luck in your career and remember always work what you love and have fun in your work or else your life will end up stagnant and monotonous with no urge to grow.

Adnan Arif

I almost cringe sometimes when strangers outside of the IT industry ask me “What do you do?” Typically one of two reactions occur – eyes glazing over with an “oh” or “what type of buildings do you design?” I’ve come up with some interesting different answers to the question ranging from “helping to design computer systems/networks” to “working with internet research” (which is much more glamorous/sexy and easy to say but not really the whole truth). I’d be interested in any good ways you’ve found to respond.

I also get asked the question from those within the IT industry and even other Systems Architects themselves which often leads to a more interesting and dynamic discussion of where a Systems Architect starts, where it overlaps, and where it ends.
The Webster definition for an architect is a person who designs and guides a plan or undertaking.

A good list of detailed responsibilities for a Systems Architect is also found at Wikipedia which is more focused on a person who has control of the big picture and overall requirements for a complex system ensuring a robust, cost effective, reliable, and strategic solution.

“The systems architect is the high-level designer of a system to be implemented. The systems architect establishes the basic structure of the system, defining the essential core design features and elements that provide the framework for all that follows, and are the hardest to change later. The systems architect provides the engineering view of the users’ vision for what the system needs to be and do, and the paths along which it must be able to evolve, and strives to maintain the integrity of that vision as it evolves during detailed design and implementation.”

A Systems Architect usually has the following responsibilities:

• Overall design – the blueprints which provide the map
• High level planning for the development – overall steps for creation of the solution from the blueprints
• Integration constraints – rules and constraints for all components going into the solution
• Adherence to standards whenever possible – to maximize the future investment value and minimizing costs
• Customization for individual customer needs – understanding and recommending the best customization based upon the customer’s needs (which include anticipation of their needs and explaining it in layman terms).

This illustration will summarize the role of a Systems Architect.

Role of a Systems Architect

My own definition is also dependent on the scope of the Architect – enterprise, for a particular business or vertical market focus, or within a specific project. The Architect will have more granular responsibilities as the scope gets tighter and the designs therefore more detailed.

Probably I should add on to my title that I design computer based systems the same way an architect builds a house – my “computer house” needs to be built with standard switches and electrical outlets for future expansion, custom features to be desirable and marketable, and cost effective to meet their budget.

Adnan Arif

Myth#1: Managers have magic pills.

Reality: Dealing with human minds is very complex and most challenging. There is no science, it’s a pure ART. Whatever you do, there will still be people who are unmanageable and there will be changes uncontrollable. In my humble opinion, a good manager can:

1. solve 50% of problems completely,
2. partially solve 15% of problems,
3. can make 15% of problems looks like no impact problem or out of scope by making them explicit with the help of communication,
4. 20% problems are such that they always remain (some people in a certain context and some changes can never be managed). We must accept this.

Please note that above figures is only an expression of my experience and not based on any scientific study or research.

Managers are also human beings who are as imperfect as anyone else. Management is a different concept with holistic approach. It’s a different profession all together that is designed to manage people and processes with imperfections. People with a good experience and study of this subject can bring a lot of value.

Myth#2: Managers always curb freedom.

Reality: May be true for some bully managers. But in reality, a good manager creates an environment that enhances performance thereby bringing BEST out of people. A manager with experience and vision may curb team’s freedom temporary but it has an objective that eventually helps people only. Sometimes people are not able to visualize that far ahead because of (a) lack of experience (b) working in extreme comfort zone (c) arrogance that always has side effect of shortening the vision (d) any other unquoted reason.

It may also be the case that incompetent people have fear of being exposed and hence, they feel managers curb freedom. People who have zest to perform should raise their bars, use manager’s experience to plug gaps and work closely with him/her thereby taking more responsibility and let the manager rest in peace.

Myth#3: Manager should not have authority.

Reality: Some countries and cultures by default inculcate responsibilities and duties in public life. The authority is not required in these cases, a coach/facilitator would work perfectly fine in these kinds of environments. But concept of authority is more relevant in those societies which are still evolving and yet to reach a maturity level. Any manager has to have authority in those environments. A manager without authority would be like a car without fuel. Studies have revealed that human mind by psychology (especially in adulthood) is like a hard iron bar which is very difficult to bend. In order to shape the iron into a beautiful vessel, authority is required. The moment, whole world becomes so diligent, responsible, mature and high performance in a self organizing manner – all management institutes would be closed globally.

Adnan Arif

1. Your idea isn’t new. Pick an idea; at least 50 other people have thought of it. Get over your stunning brilliance and realize that execution matters more.

2. Stealth startups suck. You’re not working on the Manhattan Project, Einstein. Get something out as quickly as possible and promote the hell out of it.

3. If you don’t have scaling problems, you’re not growing fast enough.

4. If you’re successful, people will try to take advantage of you. Hope that you’re in that position, and hope that you’re smart enough to not fall for it.

5. People will tell you they know more than you do. If that’s really the case, you shouldn’t be doing your startup.

6. Your competition will inflate their numbers. Take any startup traffic number and slash it in half. At least!

7. Perfection is the enemy of good enough. Leonardo could paint the Mona Lisa only once. You, Bob Ross, can push a bug release every 5 minutes because you were at least smart enough to do a web app.

8. The size of your startup is not a reflection of your manhood. More employees do not make you more of a man (or woman as the case may be).

9. You don’t need business development people. If you’re successful, companies will come to you. The deals will still be distractions and not worth doing, but at least you’re not spending any effort trying to get them.

10. You have to be wrong in the head to start a company. But we have all the fun.

11. Starting a company will teach you what it’s like to be a manic depressive. They, at least, can take medication.

12. Your startup isn’t succeeding? You have two options: go home with your tail between your legs or do something about it. What’s it going to be?

13. If you don’t pay attention to your competition, they will turn out to be geniuses and will crush you. If you do pay attention to them, they will turn out to be idiots and you will have wasted your time. Which would you prefer?

14. Startups are not a democracy. Want a democracy? Go run for class president, Bueller.

15. You’re doing a web app, right? This isn’t the 1980s. Your crummy, half-assed web app will still be more successful than your competitor’s most polished software application.

16. You will have at least one catastrophe every three months.

17. Outsource effectively, or be effectively outsourced.

18. Do you thrive on stress and ambiguity? You’d better.

19. The best way to get outside funding is to be successful already. Stupid but true. But you, cheapskate, don’t need money, right?

20. People will think your idea sucks. They’re even probably right. The only way to prove them wrong is to succeed.

21. A startup will require your complete attention and devotion. Thought your first love in High School was clingy? You can’t take out a restraining order on your startup.

22. Being an entrepreneur requires a healthy amount of ignorance. Note I did not say stupidity.

23. Your software sucks. So what. Everyone else’s does also, and re-architecting is the kiss of death for a startup. Startups are no place for architecture astronauts.

24. You do have a public API, right?

25. Abject Terror. Overwhelming Joy. Monstrous Greed. Embrace and harness these emotions you must.

Quoted from Mark Fletcher, Founder of Bloglines.com

Adnan Arif

I can’t live without Internet like many of you belonging to this new IT era. You will never find me alone anywhere because I will be in the company of my IPhone, HTC Touch PRO or Laptop. I am a gadget lover and if you are planning to give me a gift, give me some gadget and I would love it. I am a die heart computer games fan and I have large collection of computer games ranging from racing, Shooter, strategy, adventure, etc. I like to watch movies whenever I get free time from my work. I have a huge collection of movies spanning 500 GB plus hard drive space, 50+ DVDs and countless CDs.

I am working as Project Manager/Systems Architect and Manager Operations at an idea based Startup Company named Allainet Corporation. I am managing the complete process including Idea conception, Feasibility Plan, Competitor Analysis, Software Architecture, Database Design, Team Planning, Task management, Graphics Design, Marketing Planning, SEO, Security, QA and Testing, Deployment Plan, Maintenance and Project Enhancement.

Currently managing team comprising of Software Engineers, Database administrators, Content Writers, SEO Engineers, QA Engineers and Testers in coordination with Networks Team and Graphics Design Team. Some of my ventures are:

• MaybeNow.com
• Barbados.com

Beside these I am involved in multiple in-house products for supporting the Development Process and Automation of the Activities. Several projects are in process of development and much more in Idea Conception and Feasibility Phase.

I will be sharing my thoughts with you folks in coming days on number of different topics excerpted from my life, work, experiences, discussions, events or thoughts. So stay tuned for some interesting reads.

Adnan Arif