Eine Eingrenzung dieses Begriffes kann momentan allerdings nur sehr schwer erfolgen. Werden in einem größeren Unternehmen mit einer IT-Abteilung Neuerungen oder Verbesserungen des IT-Systems gewünscht, so wird das Consulting Unternehmen einem IT-Consultant diesen Auftrag übergeben. Bewegt sich ein Unternehmen selbst in der IT-Branche ist für den IT-Consultant ebenfalls ein Einsatz möglich, genauso wie eine unterstützende Beratung.

Im Bereich Consulting ist es unter anderem möglich, freiberuflich tätig zu werden. Da der Begriff des IT Consulting nicht geschützt ist, wäre eine Ausbildung in dieser Richtung auch nicht notwendig. Kenntnisse müssen allerdings im Schwerpunkt Software vorhanden sein, dabei ist es unerheblich, ob man sich diese Kenntnisse während einer Weiterbildung oder im Rahmen eines Studiums angeeignet hat. Ein IT Consulting kann für ein Unternehmen vor allem im Bereich Datenbanken eine kompetente Anlaufstelle sein.

Ein Datenbanken Consulting umfasst Dienstleistungen, wie die Anschaffung der richtigen Software, die Einrichtung dieser sowie eine Unterweisung der Mitarbeiter für eine optimale Nutzung der Software. Bei einem Consulting im Hinblick auf eine geeignete Software, ist es besonders wichtig, dass sich der IT-Consultant bereits von A bis Z mit dieser auskennt und dass diese Software vor allem den Bedürfnissen des Unternehmens auch entspricht. Da die Unternehmen in den kommenden Jahren mehr und mehr mit Datenbanken arbeiten werden, kann sich dies nur positiv auf Entwicklung des IT Consulting auswirken.

Bei der Gelegenheit wünschen wir natürlich auch den Männern alles Gute, denn immerhin haben die männliche Zunft in den ersten Monaten genauso wenig Schlaf wie das weibliche Geschlecht.

Bei dieser Gelegenheit habe ich ein paar tolle Geschenke in meinem Domain Portfolio gefunden. MacBook Air und Finanzseiten … einfach kurze PM per Twitter.

Was das genau ist, bleibt unser Geheimnis. Aber so viel vorweg: es ist etwas Neues und es ist einfach (verdammt einfach!)

Server, Technik und Administrationsoberflächen

Davor haben wir aber erstmal noch mit der Technik zu kämpfen. Stichwort: Domainumzug. Aufmerksame Leser unseres Blog haben sicherlich festgestellt, dass wir umgezogen sind. Die Domain wurde umgezogen.
Soweit so gut.
Das neue zuhause des Blogs ein VServer, leider erstmal mit einer SuSE 10.3 – wer Suse kennt – ohne Worte. Für alle anderen, die nicht gerade seit über 8 Jahren mit SuSE Linux vertraut sind: SuSE macht alles anders als alle anderen und ändert dort, wo man eigentlich keine Änderungen erwartet.

Dazu kam dann noch eine sehr schöne Administrationsoberfläche, die sämtliche Rechte des Webservers so verbogen hat, dass man mit selbigen nichts aber auch gar nichts mehr anfangen konnte.

Neuinstallation des Linux

Dritte Neuinstallation des OS geglückt. (Nichts gegen virtuelle Server und die Möglichkeit, Images schnell einzuspielen). Jetzt noch ImageMagick (jeder weiss, welche Pein das sein kann), Ruby Enterprise Edition und Passenger installieren und es läuft alles – auf der staging area. Dem Production Server noch eine zweite IP-Adresse verpassen, den Apache auf diese aufmerksam machen und dem Deployment steht nichts mehr im Wege. Oder? Doch, das deploy-Skript muss noch geschrieben werden – und das über die stages hinweg

Fazit: Entwicklung einer Applikation ist nur ein Stück des Kuchens. Diese dann der Öffentlichkeit in der richtigen Art und Weise zu präsentieren, ist der andere Teil.

Was ist Mplace?

Das werdet ihr erfahren, wenn Mplace die ersten Schritte in Richtung Web2.0 Welt bestreitet. Also unbedingt den RSS-Feed des Blogs abonnieren oder uns bei Twitter followen.

Aber beginnen wir dort, wo man beginnen sollte: am Anfang.

Betrachten wir so ein Unternehmen mal wie ein Projekt, was würden wir als erstes tun? Richtig, ein Ziel definieren. Diese Zieldefinition sollte eine Beschreibung der Idee sein und wie die Beteiligten ihre Rolle auf dem Weg zur Erreichung sehen. Damit hätten wir zumindest den Gegenstand unseres Handelns und uns selbst definiert. Dies muss nicht in einem Pamphlet biblischen Ausmaßes enden, wenn man in der Lage ist, alles in knackigen Worten in einen Absatz zu bekommen. Das Machwerk names Businessplan kommt später.

Wenn wir also wissen, was zu machen ist, müssen wir jetzt klären, wie wir es anstellen. Dazu sollte die zweite Phase unseres Projektes dienen: die Planung. Das umfasst, wie sich unsere zwei Protagonisten organisieren sollten (sowohl grundsätzlich, also als Firma, und bezogen auf die Aufgabe der Umsetzung der “technischen” Idee, also die Projektorganisation). Da der grundsätzliche Organisationsteil meist mit weitreichenden Folgen verbunden ist, sollte man hier wenn möglich jemanden zu Rate ziehen. Die Projektorganisation sollten beide hinbekommen, da sie aus dem Projektumfeld kommen.

So, wir wissen jetzt was wir wie tun wollen. Dann geht es jetzt an das Umsetzen. Für diese Phase gibt es, außer ein paar gut gemeinten Ratschlägen und der Hinweis zum Einhalten der selbstgesteckten Grundsätze, wenig zu sagen. Es wird die erste Nagelprobe der beiden werden. Und ob einfach wirklich einfach ist. Auf alle Fälle sollten die beiden getreu dem Grundsatz der “Getting Real”-Bewegung häufig und schnell etwas Online stellen.

Das führt uns aber zum nächsten Punkt (wenn wir davon ausgehen, dass die Testphase Bestandteil der Realisierung ist): der Transition (in gutem Neudeutsch). Also die Überführung der entwickelten Idee in den Betrieb. Jetzt wird der ein oder andere anmerken, dass wir doch kein großen IT-Projekt mit tausenden involvierten Mitarbeitern in Produktion bringen. Richtig, vordergründig würde man sofort an diese Größenordnung denken. Aber egal welche Größe ein Projekt hat, eine Transition sollte in jedem Fall durchgeführt werden. Fällt sie halt nicht so kompliziert aus. Einfach ist das Zauberwort. Bei agilem Entwicklungsansatz wird sich diese Transition sowieso in Portionen immer wieder wiederholen. Das trainiert.

Jetzt kann das Geldverdienen losgehen. Und auch das will mit Bedacht getan werden. Mir fällt zwar keine Phase mehr ein, aber sicher finden sich auch hierfür ein paar schlaue Worte.

Jetzt sollten wir doch den groben Fahrplan haben, oder? Ins Detail gehe ich dann in den Fortsetzungen. Und zwar Schritt für Schritt. Andere entwicklen in der Zeit zwar komplette, funktionierende System (siehe letzter Railsrumble), aber stehen dann da mit ihrem System und haben keine Organisation drumrum

Wir werden sie begleiten und ihnen versuchen, eine Checkliste zu erstellen, die es ihnen ermöglicht, ihre simple Idee auch simple seien zu lassen.

Lasst mich kurz die Ausgangssituation beschreiben, damit die anstehenden Aufgaben klar werden.

Also, unsere zwei Protagonisten haben eine einfache Web-Idee, die wenig Entwicklungsaufwand für den Start erfordert. Sie haben sich dabei dem sogenannten agilen Entwicklungsweg verschrieben. Aus ihren anderen Web-Aktivitäten haben sie die notwendige Technik parat, die eigentlich nur noch zum Zusammenspiel koordiniert werden muss. Somit sollte die technische Seite in der Tat das geringste Problem darstellen.

Aber zu einem Unternehmen gehört mehr. Und zwar Geld. Ausgerechnet das haben die zwei aber nicht, zumindest nicht in Form exorbitanter Budgets. Somit wollen sie das Bisschen, das sie haben, auch effizient einsetzen.

Sie müssen sich um eine Organisationsform kümmern, die einfach und preiswert ist, sie im Fall des Misserfolgs aber nicht in den Abgrund reisst.

Und dann sind da noch die tausend anderen Kleinigkeiten, die das Leben so prickelnd machen und für einen immer währenden Strom der Freude und Arbeit sorgen.

Aber dazu mehr im zweiten Teil unseres Reports.